Professional Documents
Culture Documents
Ccie Wireless v3 Study Guide
Ccie Wireless v3 Study Guide
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Title Page
CCIE Wireless v3 Study Guide
Carlos Alcantara, CCIE R&S and Wireless No. 16523
Nicolas Darchis, CCIE Wireless No. 25344
Jérôme Henry, CCIE Wireless No. 24750
Jeal Jiménez, CCIE Wireless No. 31554
Federico Ziliotto, CCIE R&S and Wireless No. 23280
Cisco Press
||||||||||||||||||||
||||||||||||||||||||
Copyright Page
CCIE Wireless v3 Study Guide
Copyright © 2019 Pearson Education, Inc,
Published by:Cisco Press
All rights reserved. No part of this book may be reproduced or transmitted in any form or
by any means, electronic or mechanical, including photocopying, recording, or by any
information storage and retrieval system, without written permission from the publisher,
except for the inclusion of brief quotations in a review.
01 18
ISBN-13: 978-1-58720-620-7
ISBN-10: 1-58720-620-x
Warning and Disclaimer
This book is designed to provide information about the CCIE Wireless certificate exam
Every effort has been made to make this book as complete and as accurate as possible,
but no warranty or fitness is implied.
The information is provided on an “as is” basis. The authors, Cisco Press, and Cisco
Systems, Inc. shall have neither liability nor responsibility to any person or entity with
respect to any loss or damages arising from the information contained in this book or
from the use of the discs or programs that may accompany it.
The opinions expressed in this book belong to the author and are not necessarily those of
Cisco Systems, Inc.
Trademark Acknowledgments
All terms mentioned in this book that are known to be trademarks or service marks have
been appropriately capitalized. Cisco Press or Cisco Systems, Inc., cannot attest to the
accuracy of this information. Use of a term in this book should not be regarded as
affecting the validity of any trademark or service mark.
Special Sales
||||||||||||||||||||
||||||||||||||||||||
Copyright Page
For information about buying this title in bulk quantities, or for special sales opportunities
(which may include electronic versions; custom cover designs; and content particular to
your business, training goals, marketing focus, or branding interests), please contact our
corporate sales department at [email protected] or (800) 382-3419.
For government sales inquiries, please contact [email protected].
For questions about sales outside the U.S., please contact [email protected].
Feedback Information
At Cisco Press, our goal is to create in-depth technical books of the highest quality and
value. Each book is crafted with care and precision, undergoing rigorous development
that involves the unique expertise of members from the professional technical
community.
Readers’ feedback is a natural continuation of this process. If you have any comments
regarding how we could improve the quality of this book, or otherwise alter it to better
suit your needs, you can contact us through email at [email protected]. Please
make sure to include the book title and ISBN in your message.
We greatly appreciate your assistance.
Editor-in-Chief: Mark Taub
||||||||||||||||||||
||||||||||||||||||||
Copyright Page
Editorial Assistant: Cindy Teeters
Americas Headquarters
Cisco Systems, Inc.
San Jose, CA
Asia Pacific Headquarters
Cisco Systems (USA) Pte. Ltd.
Singapore
Europe Headquarters
Cisco Systems International BV Amsterdam,
The Netherlands
Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers
are listed on the Cisco Website at www.cisco.com/go/offices.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its
affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this
URL: www.cisco.com/go/trademarks. Third party trademarks mentioned are the property
of their respective owners. The use of the word partner does not imply a partnership
relationship between Cisco and any other company. (1110R)
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Dedications
Dedications
Carlos Alcantara: This book is dedicated to my beautiful wife and three awesome
younglings; they are truly an inspiration. They are my motivation, moving toward new
goals and embarking on new challenges. I could not have been a part of this project
without their love, support, and patience.
Nicolas Darchis: I would like to thank my very patient wife, Caroline, and my kids, who
have been extremely understanding all the times that I had to make myself unavailable
while authoring this book. I also wanted to thank my colleagues at the wireless TAC
teams who, directly or indirectly, helped me build the knowledge required (and used) to
write this book.
Jeal Jiménez: I would like to dedicate this effort to my wife, Sofia, and all the
family/community members for their support throughout a journey that started long
before this book. I also want to dedicate this book to all the people dealing with Wi-Fi
and looking to learn and grow in their careers while working hard not only to achieve
CCIE or other certification, but also on their personal networking journey. Keep it up!
This book will be helpful for any of you working with Cisco WLAN technologies. I hope
you enjoy the book and learn a lot from it.
Federico Ziliotto: I would like to address a huge THANK YOU to my colleagues and
managers from my team at Cisco, for having supported and backed me up while I wrote
these chapters. To Vincent, Jean-Louis T., Jérôme, Thao, Sébastien, Jean-Louis S.,
Michael, Guy, Christophe—and all the others who I am unfortunately not able to list here
—you’ve all been a tremendous help. A very warm and grateful mention to my parents
and family, too, who tolerated me working during family reunions and holidays, and who
kept encouraging me about that book I should have been writing when I was not. Last,
but definitely not least, a special “merci” to Laura for her love, patience, fun, and for
having made me discover new dimensions of tooth-breaking sweets that cheered me up
when energy was mostly needed.
10
||||||||||||||||||||
||||||||||||||||||||
Acknowledgments
Acknowledgments
All the authors would like to give special recognition to Sam Clements for providing his
expert technical knowledge in editing the book. He has provided outstanding advice and
recommendations, which helped us create a more complete and accurate book.
A big ‘thank you’ goes out to the editorial and production team for this book. Ellie C.
Bru, Michelle Newcomb, Brett Bartow, and Tonya Simpson have been incredibly
professional and a pleasure to work with. They have made this book possible, and we
couldn’t have asked for a finer team.
All the authors would also like to thank Santiago Lopez, who organized and gathered the
authors, set up meetings, and made sure everything was constantly on track. Without
him, this book would not have seen the light of day.
11
||||||||||||||||||||
||||||||||||||||||||
Contents at a Glance
Contents at a Glance
Foreword
Introduction
Chapter 1 Planning and Designing WLAN Technologies
Chapter 2 Network Infrastructure
Chapter 3 Autonomous Deployments
Chapter 4 AireOS Appliance, Virtual, and Mobility Express Controllers
Chapter 5 Wireless Security and Identity Management with ISE
Chapter 6 Prime Infrastructure and MSE/CMX
Chapter 7 WLAN Media and Application Services
12
||||||||||||||||||||
||||||||||||||||||||
Contents
Contents
Foreword
Introduction
Chapter 1 Planning and Designing WLAN Technologies
Describe WLAN Organizations and Regulations
802.11 Standards and Protocols
802.11 Amendments for Faster Speed
802.11 Amendments for Cell Efficiency
Plan and Design Wireless Solutions Requirements
RF Planning, Design, and Validation
RF Design and Site Survey
Using a Planning Tool
Onsite Surveys
Deployment Models
RF Operational Models
Deployment Validation
Summary
Chapter 2 Network Infrastructure
Introduction
Switching Technologies
VLANs
13
||||||||||||||||||||
||||||||||||||||||||
Contents
Private VLANs
VLAN Trunking Protocol
Spanning Tree Protocol
STP Tuning Commands
Multiple Spanning Tree
Spanning Tree and Wireless
EtherChannel
CDP and LLDP
Power over Ethernet for Access Points
IP Layer Refresher
IPv4
IPv6
Multicast
Infrastructure Security for Access Points
MAC Authentication Bypass
802.1X
Configuring the Access Point for Authenticating
Configuring the Switch
Configuring ISE
Advanced Settings and Special Cases
14
||||||||||||||||||||
||||||||||||||||||||
Contents
Securing FlexConnect APs
Other Protocols Supporting Wireless
SNMP
DHCPv4
DHCPv6
DNS
SYSLOG
NTP
Summary
Chapter 3 Autonomous Deployments
The Role in the Deployment
Root and Non-Root Bridges
Workgroup Bridge
Mobile WGB
Workgroup Bridges for High-Speed Roaming
Cisco IOS Autonomous Security
Layer 2 Wireless Security
802.1X Supplicant at the Non-Root/WGB
Local RADIUS Server at the Root
Filters
Radio Settings
15
||||||||||||||||||||
||||||||||||||||||||
Contents
Channels
Parents
Transmitter Power
Antennas
Data Rates
Multicast on Autonomous
QoS for Bridging
Summary
Chapter 4 AireOS Appliance, Virtual, and Mobility Express Controllers
Mobility Express
Securing Management Access and Control Plane
Admin User Authentication and Authorization
CPU Access Control Lists
Management via Wireless and via Dynamic Interface
Working with WLC Interfaces
Management and AP-Manager Interfaces
Service Port
Virtual Interface
Dynamic Interfaces
LAG: Link Aggregation
Deploying Lightweight Access Points
16
||||||||||||||||||||
||||||||||||||||||||
Contents
Authenticating and Authorizing APs on the Network
AP Modes of Operations
Accessing Configuration Settings and Logging Options for APs
High Availability and Redundancy
N+1 and N+N High Availability
AP and Client Stateful Switch Over
Segmenting Your Wireless Network
RF Profiles
AP Groups
FlexConnect Groups
Wireless Security Policies
To Layer 2 or To Layer 3?
WLAN Security Options
Rogue Policies
Local EAP, Local Profiling, and Local Policies
ACLs and Certificates
FlexConnect Deployments
What Problem Are We Trying to Solve?
FlexConnect Modes and States
FlexConnect Specific Features
FlexConnect Group Specific Features
17
||||||||||||||||||||
||||||||||||||||||||
Contents
OfficeExtend
Configuring and Troubleshooting Mesh
AWPP and Mesh Formation
Mesh Topologies
AWPP and Mesh Formation
Mesh Configuration
Mesh Basic Configuration
Mesh Page Optional Configurations
Mesh Security Configurations
Mesh Local Bridging Configurations
Troubleshooting Mesh
Radio Frequency Management
What Problem Are We Trying to Solve?
Static Assignment
Global Assignment (RRM)
Off-Channel Scanning
RF Grouping
Flexible Radio Assignment
Dynamic Channel Assignment
Coverage Hole Detection and Mitigation (CHDM)
CleanAir
18
||||||||||||||||||||
||||||||||||||||||||
Contents
Transmit Power Control
RF Profiles
Data Rates
RX-SoP
AirTime Fairness
Configuring and Troubleshooting Mobility
Layer 2 and Layer 3 Roaming
Mobility Lists and Groups
Mobility Messaging
Mobility Anchors
Troubleshooting Mobility
Wireless Client Roaming Optimization
Band Select
Load Balancing
Optimized Roaming
802.11k and 802.11v
Fast-Secure Roaming
CCKM
802.11r/FT
Summary
Chapter 5 Wireless Security and Identity Management with ISE
19
||||||||||||||||||||
||||||||||||||||||||
Contents
Identity Management Building Blocks
802.1X
802.1X Components
EAP
EAP Methods
RADIUS
RADIUS Attributes
CoA
AAA Sequence
Identity Services Engine Deployment and Configuration
ISE Certificates
Network Access Policies
Authentication Policy
Authorization Policy
Profiling Policy
Guest Access
Guest Services
Sponsor Services
ISE Integration with Active Directory
Device Administration Policies
Policy Sets
20
||||||||||||||||||||
||||||||||||||||||||
Contents
Authentication Policy
Authorization Policy
Configuring ISE for Wireless
Common Configuration
Wireless RADIUS Attributes
802.1X
MAC Filtering and MAC Authentication Bypass (MAB)
Local Web Authentication
Central Web Authentication
Profiling
Wireless Device Administration via ISE
Summary
Chapter 6 Prime Infrastructure and MSE/CMX
Managing the Management
Basic Operations
Working with Devices, Templates, and Audits
Operating Maps
High Availability
Monitoring Tools: Troubleshooting Clients and Working with Reports, Alarms and
Events, and Notifications
Configuring Jobs
21
||||||||||||||||||||
||||||||||||||||||||
Contents
Security Operations
Mobility Services Engine and Connected Mobile Experiences
Location Technologies and Techniques
Cell of Origin and Presence
Trilateration with Probe RSSI or FastLocate
802.11 Active RFID Tags
Angle of Arrival (AoA) and Hyperlocation
Bluetooth Low Energy
Management Access
Network Services
Location
Analytics
Connect and Engage
CleanAir
Wireless Intrusion Prevention System
NMSP
Summary
Chapter 7 WLAN Media and Application Services
Introduction
QoS Survival Concepts for Wireless Experts
The Notion of Differentiated Treatment
22
||||||||||||||||||||
||||||||||||||||||||
Contents
QoS Design
Application Visibility and Identification
Layer 3, Layer 2 QoS
IPv4 QoS Marking
Per Hop Behavior
IPv6 Layer 3 Marking
Layer 2 802.1 QoS Marking
802.11 QoS Marking
DSCP to UP and UP to DSCP Marking
Downstream
Upstream
Trust Boundary and Congestion Mechanisms
Trust Boundary
Congestion Management
802.11 Congestion Avoidance
TXOP
CAC
BW Contracts
Configurations
AireOS
QoS Profiles and Bandwidth Contracts
23
||||||||||||||||||||
||||||||||||||||||||
Contents
Default QoS Mapping
DSCP Trust and 802.11u QoS Maps
EDCA Parameters
WLAN and WMM Configurations
CAC Configuration
Data Rate Configuration
AVC Configuration
FastLane Configuration and Client Behavior
Enhanced Roaming
Managing Video Flows
Bonjour/mDNS
Bonjour/mDNS Principles
Bonjour/mDNS Configuration
mDNS Gateway
mDNS Profiles
mDNS AP
mDNS Filtering Options: Priority MAC, Origin, and LSS
LSS
mDNS Policies
AireOS Configuration Summary
Autonomous APs
24
||||||||||||||||||||
||||||||||||||||||||
Contents
DSCP to UP Mapping
Retry Options
EDCA Parameters
Advanced Features
Autonomous Application Service Configuration Summary
Wired Configuration
Trusting DSCP or CoS
QoS Policies
Class Maps
Policy Maps
Service Policy
Summary
25
||||||||||||||||||||
||||||||||||||||||||
Reader Services
Reader Services
Register your copy at www.ciscopress.com/title/9781587206207 for convenient access to
downloads, updates, and corrections as they become available. To start the registration
process, go to www.ciscopress.com/register and log in or create an account*. Enter the
product ISBN 9781587206207 and click Submit. After the process is complete, you will
find any available bonus content under Registered Products.
*Be sure to check the box that you would like to hear from us to receive exclusive
discounts on future editions of this product.
26
||||||||||||||||||||
||||||||||||||||||||
27
||||||||||||||||||||
||||||||||||||||||||
28
||||||||||||||||||||
||||||||||||||||||||
Foreword
Foreword
As I think of an opening for this book, one single thought springs to mind: The wait is
over. That thought puts a big smile on my face. It’s been a long, long time since we last
had a CCIE Wireless book. Back in the year 2012, 802.11n was the prevalent wireless
technology. Since then, nearly 7 years have passed, and our wireless world has evolved
enormously. We now have a ratified 802.11ac and “ax” is almost around the corner, not
to mention WPAv3. Wi-Fi (along with coffee) forms a definitive part of that extremely
important list of basic human needs, and who could argue otherwise? Wi-Fi has long
become the de facto access layer—at home, at the office, and on the move. In an era
where we are constantly connected, wireless is, literally, everywhere.
The CCIE Wireless itself, as a certification, has undergone a couple of updates over the
past few years:
v2.0 was released on November 18, 2011, shortly before the previous CCIEW book
was released (on April 12, 2012).
v3.0 was released on September 14, 2015.
v3.1 release was introduced on November 8, 2017.
The updates reflect the changes that we have seen over the past few years in our
corporate networks, where we no longer work with ACS, WCS, or even Converged
Access, but with ISE, PI, CMX, and APIs, while “Automation,” “Network
Programmability,” “DNA,” and “Intent” are the new buzzwords that we hear every day,
and that we know we will have to become accustomed to working with sooner or later.
All these changes have been and continue to be profound. They put extra pressure on the
wireless professional but they have also been welcomed, because they have enabled us to
build more robust, secure, and sophisticated wireless networks while creating a more
enjoyable and enhanced user experience.
But having a new CCIE Wireless book out is not the only reason why this book puts a big
smile on my face. I had the great, great privilege of hand picking the authors who put
together this content and, knowing who they are, I had great expectations for the book.
To say that the team delivered above and beyond my expectations wouldn’t be enough;
as I read through each chapter, that big smile kept spreading across my face, and I am
sure you will have the very same feeling as you go through the content. I am indebted to
each one of you for your contribution and, indeed, I think that it would be fair to say that
29
||||||||||||||||||||
||||||||||||||||||||
Foreword
this could be extended to the bigger wireless community.
Last, but certainly not least, I would like to say a big thank you to Sam Clements for
being the technical editor. He is a friend, a key contributor to the CCIE Wireless
program, and a credit to the wireless community.
I hope you enjoy the book and that you find it an excellent first step into your CCIE
Wireless journey!
Santiago Lopez, CCIE Wireless No. 46087
CCIE Wireless Program Manager
Learning@Cisco
August 2018
30
Technet24
||||||||||||||||||||
||||||||||||||||||||
Introduction
Introduction
Welcome to your CCIE Wireless journey. This book aims to be your preparation bible
during that long and challenging (but also rewarding) journey that is the CCIE Wireless.
We, the authors, hope to have put the right balance of content to help you through your
preparation to reach CCIE heaven, and that the book not only helps you through that
journey but also serves as a motivational trigger.
The prestige and respect associated with being a CCIE Wireless will definitely help you
in your career. Still, for those readers who are not yet on that path, we hope to provide
you with a thorough understanding of the Cisco WLAN technologies. Equipped with this
knowledge, you will be able to more effectively overcome challenges in your wireless
deployments and be a better overall wireless professional.
The CCIE Wireless certification assesses and validates wireless expertise. Candidates
who pass the CCIE Wireless certification exams demonstrate broad theoretical and
practical knowledge of wireless networking, as well as a solid understanding of WLAN
technologies from Cisco.
There are no formal prerequisites for CCIE certification. Other professional certifications
or training courses are not required. Instead, candidates must first pass a written
qualification exam and then the corresponding hands-on lab exam. You are expected to
have an in-depth understanding of the exam topics and are strongly encouraged to have
three to five years of job experience before attempting any CCIE certification.
For the latest CCIEW Wireless news and blueprint, visit
https://learningnetwork.cisco.com/community/certifications/ccie_wireless.
31
||||||||||||||||||||
||||||||||||||||||||
32
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
34
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figure Credits
Figure Credits
Chapter 2, Figures 2-33 and 2-34 screenshots of DHCPv6 © Wireshark.
Chapter 4, Figure 4-16 screenshot of Ekahau © 2018 Ekahau.
Chapter 7, Table 7-2, “Classes of Service Names and Values” © IEEE 802.1Q, “Media
Access Control Bridges and Virtual Bridged Local Area Networks,” Patricia Thaler,
Norman Finn, Don Fedyk, Glenn Parsons, Eric Gray
Chapter 7, Table 7-3, “802.1p / 802.1D-2004 Classes” © Traffic priority, IEEE 802.1p,
Mario Baldi, Pietro Nicoletti
Chapter 7, Figure 7-35 screenshot of Apple iOS © Apple, Inc.
35
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
802.11 was published in 1997 and clarified in 1999, but it is obsolete today. It allowed for features, such as
infrared communications, which were never implemented, and allowed for only 2 Mbps maximum. Since then,
five amendments were passed to increase the speeds allowed in 802.11:
802.11b: The IEEE 802.11b standard, ratified in September 1999, operates in the 2.4 GHz spectrum and
supports data rates of 1 Mbps, 2 Mbps, 5.5 Mbps, and 11 Mbps. The original 802.11-1997 protocol
allowed IR, Frequency Hopping Spread Spectrum (FHSS), and Direct Sequence Spread Spectrum (DSSS),
whereas the 802.11b protocol allows only DSSS, using Barker code or Complementary Code Keying
(CCK).
802.11a: The IEEE 802.11a standard operates in the three 5.0-GHz UNII frequency bands, with data rates
of 6, 9, 12, 18, 24, 36, 48 Mbps, and a maximum data rate of 54 Mbps. The IEEE required only
mandatory support of data rates of 6, 12, and 24 Mbps, because each of these rates used a different
modulation (BPSK, QPSK and QAM). Mandating such support was a way to force vendors to implement
all the modulations. Using the 5 GHz spectrum, 802.11a has up to 25 nonoverlapping frequency channels
(depending on the geographic area), compared to the three nonoverlapping channels of 802.11b/g.
802.11g: The IEEE 802.11g standard, which was ratified in June 2003, operates in the same spectrum as
802.11b and is backward compatible with the 802.11b standard. 802.11g supports the additional data rates
of 6 Mbps, 9 Mbps, 12 Mbps, 18 Mbps, 24 Mbps, 36 Mbps, 48 Mbps, and 54 Mbps. 802.11g delivers the
same 54 Mbps maximum data rate and the same modulations as 802.11a.
802.11n: IEEE 802.11n was ratified in 2009. The 802.11n standard increases the speeds available to
802.11 by increasing the possible channel width, from 20 MHz (802.11g/a) to 40 MHz. 802.11n also uses
spatial multiplexing, which utilizes a concept called multiple input, multiple output (MIMO). By the mid-
2000s, the WI-FI chipset had built a better efficiency to send and receive in noisy environments.
Leveraging these advances, MIMO allows up to 4 antennas and associated radios to transmit (or receive)
at the same time, increasing the Tx/Rx speeds. 802.11n operates in the 2.4 GHz and 5 GHz bandwidths
and is backward compatible with 802.11a and 802.11g (but not with 802.11b).
802.11ac: The IEEE 802.11ac standard was published in 2013 and is designed to operate exclusively in
the 5 GHz band. 802.11ac increases the channel width to 80 and 160 MHz, and also allows for
downstream transmissions to more than one recipient at the time (Downlink Multi User MIMO, DL-MU-
MIMO). This mode also allows for faster transmission because most handheld devices are limited to one
39
||||||||||||||||||||
||||||||||||||||||||
More than 30 amendments were published since the original version of 802.11 in 1997. This chapter does not
list them all. However, some of them will be detailed and configured in the next chapters, and you need to
understand what problems they were intended to solve:
802.11d: Also called world mode, 802.11d was published in 2001. This amendment allows the AP and the
station to exchange information on the country of operation (including list of channels and max power).
This is critical when your Wi-Fi client joins Wi-Fi networks in different regulatory domains.
802.11h: Called Spectrum and Transmit Power Management Extensions in the 5 GHz Band in Europe,
802.11h was published in 2003. It was then implemented in most other regulatory domains in 2007 and
later. 802.11h describes how operations in the 5 GHz should avoid collision with airport radar activities.
802.11h is critical for outdoor mesh operations, and for indoor operations in UNII-2 and UNII-2e. A
system is allowed to operate in these bands only if it can detect radar blasts and then vacates the affected
frequency for at least 30 minutes (using a mechanism called Dynamic Frequency Selection, or DFS). A
system should also not use any channel in the affected bands without first checking that no radar is
detected using it. Because of these requirements, roaming efficiency is limited when using these channels.
802.11e: Published in 2005, 802.11e includes provisions for QoS over Wi-Fi. Critical for real-time
applications, 802.11e describes differentiated services for different types of traffic, increasing the
statistical probability of access to the medium (in case of contention) for traffic in categories with higher
priority.
802.11k: Published in 2008, 802.11k describes functions for radio resource management. One of the main
features of this amendment that will be discussed in this book is the neighbor list, which allows an AP to
send to a client a list of neighboring APs that the client can roam to. This short list is intended to save on
scanning time. It is only efficient if the view from the AP is the same as the view from the client.
802.11r: Published in 2008, 802.11r describe provisions for fast key exchange during roaming. This
mechanism is called Fast Transition (FT) and is critical for time-sensitive applications in networks where
encryption is in place.
802.11w: Published in 2010, the Protected Management Frames (PMF) amendment aims at protecting
clients against AP impersonation attacks. This protocol was derived from the Cisco Management Frame
40
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Quite clearly, the complexity of the environment to cover will drive the type of survey you will want to
perform. In simple and small locations, a virtual tool may be enough. “Simple” in this context means an open
floor plan with a limited number of planned access points. However, limiting yourself to a virtual survey by
using a planning tool, without ever going onsite, is a recipe for a disaster, because you cannot account for the
existing RF environment and any source of electromagnetic signal that may potentially interfere with your
setup. These sources can be other Wi-Fi systems, but also any other electronic device that emits energy in the
ISM bands that Wi-Fi also use. This emission is possible even if the sources are not communication devices.
Because the ISM bands are by definition unlicensed, many types of objects may be authorized to emit signals
in these frequencies, as long as the signals respect the local regulations in terms of power and signal structure.
Unless you are onsite, you cannot guess what devices may be interfering with your planned Wi-Fi signals.
Nevertheless, using a planning tool is useful to prepare for the site survey. As illustrated in Figure 1-1, such a
tool allows you to have a first estimate of the number of access points needed, based on the main application
and the floor layout.
||||||||||||||||||||
||||||||||||||||||||
Onsite Surveys
After the survey preparation is complete, you should know what type of coverage is intended, how long the
survey is expected to last, and what areas are likely to be more problematic than others to survey and cover.
You should also be ready with a survey kit that includes the APs that you plan to deploy onsite and a set of
antennas that will match all the types of coverage shapes you may need.
Onsite, a traditional approach is to start with a Layer 1 sweep, using tools such as MetaGeek Chanalyzer. This
first sweep will allow you to evaluate the local interferers, locate them, and assess their impact on your
channel plan. At this point, you may have to discuss this with your customer if some interferences cannot be
worked around.
You should also conduct a passive Wi-Fi site survey, which captures the state of the existing Wi-Fi networks.
This is done with a site survey tool (for example, Ekahau Site Survey), without connecting to any particular
SSID, by scanning all channels and mapping the signals detected at each location to a floor plan. Unless the
building is new and isolated, you are likely to find existing Wi-Fi systems, which may limit your choice of
channels and power limits.
The next step is to determine the placement of each intended AP. This is done by performing an active site
survey (where your test device actually associates to the SSID configured on your test AP).
Note
In Cisco courses and exams, the terms “passive” and “active” site surveys are defined as detailed earlier.
However, some survey tools use a different terminology. You should be aware that the industry has not
adopted yet a uniform naming convention for passive and active surveys.
A common method to perform this step is to first place the AP at the edge of the coverage area—for example,
a corner of the building—then determine the coverage boundary for the desired rate and power level. This
principle is illustrated in Figure 1-2.
44
Technet24
||||||||||||||||||||
||||||||||||||||||||
The logic is that if you get coverage up to point (2) when the AP is at position (1) on the left side of the
illustration, then you should get coverage down to point (1), which is the corner of the building, when the AP
is at position (2). Position 2 is located along the coverage boundary determined when the AP was in position
(1), preferably at equal distances from each building wall, which places the AP toward the center of the
building. After you have determined position 2, move the AP there. This is expected to be the final position of
your AP for this zone. Perform a site survey to determine the zones where the data rate falls to the minimum
acceptable value. This zone represents your coverage boundary. Next, determine the overlap between cells
(how deep inside the local cell the next cell should be allowed to extend its coverage above the minimum data
rate, as detailed further in the next section) and position the next AP until the overlap matches your design.
Repeat this logic until the entire floor is covered.
Deployment Models
The size of each cell and the minimum data rate allowed will depend on the most critical applications expected
in the deployment. In all cases, the expected power of the AP is expected to match the expected power of the
target clients. This recommendation may bring you to limit the upper value of RRM Transmit Power Control
(TPC). For example, most laptops can achieve 20 dBm, but many phones only reach 14 dBm. Even if APs
have a better receive sensitivity than most clients (for which antenna position is constrained by form factor), a
large mismatch between the client and AP power is conducive to losses at the edge of the cell.
In large spaces where only basic data traffic is expected, all rates may be allowed. The cell size in such spaces
may reach or exceed 8000 sq. ft. (750 sq. m.). With low data rates allowed at the edge of the cell, clients will
achieve only low throughput, but the goal of such deployment is coverage, not performance.
As the requirements for throughput increase, the AP power does not change, but the minimum data rate
allowed will increase. The determination of the minimum data rate depends on the throughput required by the
most demanding business-critical application, and the expected quantity of users running that application at
any time from the edge of a cell. For example, if the most critical business application requires 2 Mbps of
bidirectional throughput, and you expect that up to 2 people will always be using the application at the same
time from the cell edge, then the minimum data rate at the edge of the cell should be 2 users × 2 Mbps × 2
directions = 8 Mbps, resulting in a minimum allowed data rate of 9 or 12 Mbps (closest higher match, 12 is
more common because it is one of the initial 802.11a mandatory rates). The legacy data rates (for example, 6
45
||||||||||||||||||||
||||||||||||||||||||
46
Technet24
||||||||||||||||||||
||||||||||||||||||||
RF Operational Models
After the AP locations have been determined, your next step is to design the RF coverage. Most clients will
try to scan for an alternate AP when the current AP power falls below −70 dBm to −75 dBm (depending on
client brand and form factor). This does not mean that your cell edges should be built at that signal level. For
basic data coverage, a cell edge at −72 dBm is common. For location, each detecting AP should read the client
signal at −75 dBm or better (−72 dBm or higher preferable). For real time applications (such as voice), a cell
edge at −67 dBm is common. This value also assumes a low noise floor, and an SNR of 20 dB (data coverage
case) or 25 dB (real-time application case). These requirements come from the 802.11 standard specifications
that dictate the minimum capabilities of clients to demodulate a signal received with a target encoding and
signal level. Figure 1-4 shows an extract of such requirements for 802.11ac.
The column header reads MCS, Channel, SS, Data Rate (NGI), RSSI Min, and SNR Min. Row 1
reads: 7, 20 Megahertz, 1 65, 76.5, nad 17.5. Row 2 reads: 7, 40 Megahertz, 1, 135, 74.5, and 19.5.
Row 3 reads: 7, 80 Megahertz, 1, 292.5, 71.5, and 22.5. Row 4 reads: 7, 20 Megahertz, 3, 195, 71, and
23. Row 4 reads: 7, 80 Megahertz, 3 1053, 63, and 31. The text below the table reads: You need 5 dB
47
||||||||||||||||||||
||||||||||||||||||||
48
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Deployment Validation
After the APs are installed, your last step is to validate whether the network performances match your design.
A first step in this direction is to walk the entire floor with a site survey tool, running a passive survey to
measure your AP’s signal. At a minimum, you should use “some” device displaying an RSSI value and
verifying your cell edges signal and cell overlap.
In all cases, you should also verify that the protocols you targeted are enabled and functional. For example, if
you designed cells around 40 MHz channels with 802.11n/ac with 2 SS and a minimum data rate of 24 Mbps,
you should walk the floor and assess that no location has any wrong settings (for example, 80 MHz 4 SS, or 6
Mbps allowed). You should pay special attention to difficult areas (high ceilings, reflective surfaces, and so
on.)
Another important area to test is rate shifting, as illustrated in Figure 1-6.
Technet24
||||||||||||||||||||
||||||||||||||||||||
Summary
Following all these steps ensures that your wireless network is not only expertly configured but also expertly
designed. As the saying goes, good configuration cannot compensate for bad design. Part of your expertise is
to know each option in the AP or WLC and understand the various ways it can be configured. But part of
your expertise is also understanding why an option is there, and what role it plays in the overall landscape of
Wi-Fi deployments. Building such knowledge requires more than reading this short chapter, and you should
make sure to master the various references indicated throughout the preceding pages.
You should also expect that the CCIE Wireless exam tests your expertise. As such, elements of configurations
that are asked from you rely on assumption of expertise in the principles of wireless design. Making sure that
you understand the core design principles is the safest way of guaranteeing that you will understand possible
unspoken requirements behind configuration instructions in the lab.
51
||||||||||||||||||||
||||||||||||||||||||
Switching Technologies
We first focus on technologies that revolve around Layer 2 before moving higher up in the OSI model layers.
VLANs
A lot can be said about VLANs, and chances are that if you are reading this, you must have an idea or two about how to use them.
What are the VLANs pros and cons with regard to wireless, though? Are the guidelines the same as for a fully wired network? Let’s
see.
A VLAN, basically, is a (virtual) Layer 2 network or subnet within your physical topology. A VLAN defines a broadcast domain—
that is, all the links where broadcasts emitted in that subnet will be sent through. It is important to realize that clients will broadcast
for ARP in IPv4, for DHCP, but also for a large amount of discovery protocols depending on their operating system. A lot of
services discover compatible devices through same-subnet broadcasts (or multicast, which will also be spread across the VLAN).
This represents a lot of traffic, and VLANs are here to help reduce the size of the domain of those broadcasts. Each VLAN will also
typically require a gateway for hosts to reach out to other subnets. This gateway can be configured on a switch or a router in the
network, where some VLAN interfaces are centralized.
You can configure a switchport to be in access mode; it is then mapped to a specific VLAN statically. No VLAN tags on the frames
are used with this method. You can therefore connect a host or PC (which typically are not VLAN aware) to such a switchport, and
the switch will automatically consider that all traffic coming from this port is mapped to the specified VLAN. It will then be
forwarded accordingly only to ports where that VLAN is configured (until a gateway routes the packet, possibly).
Click here to view code image
Switch1(config)# interface Gig0/1
Switch1(config-if)# switchport mode access
Switch1(config-if)# switchport access vlan 20
The preceding is traditionally used to configure ports where hosts or end devices connect. However, links between infrastructure
52
Technet24
||||||||||||||||||||
||||||||||||||||||||
The figure shows an Original Ethernet Frame with the following headers: DA, SA, Type/Len, Data, and FCS (crossed-out).
The Ethernet Frame with 802.1q Tag contains: DA, SA, Tag, Type/Len, Data, and FCS. The tag header, of 4 bytes,
includes the headers EtherType (2 bytes, value = 0x8100), PRI (3 bits, 0-7), Token Ring Encapsulation Flag (1 bit, 0-1),
and VLAN ID (12 bits, 0-4095).
It is good practice to always restrict the VLANs of a trunk to the required VLANs, to avoid unneeded broadcasts traveling insane
distances. A trunk port by default will use VLAN 1 as native, which means that all frames in VLAN 1 will not have any 802.1Q
encapsulation header. It also means that the switchport will consider all non-802.1Q tagged traffic it receives to belong to VLAN 1.
This native VLAN can be changed with switchport trunk native vlan <id>. It is important that both ends of a trunk port consider
the same VLAN to be the native; otherwise, you will be bridging two different VLANs together. Indeed, if the first switch sends a
frame in VLAN 5, and VLAN 5 is the native for that switch, the frame will be sent without any 802.1Q tag. If you then imagine that
the connected switch is configured to consider VLAN 1 as the native, and it receives an untagged frame, it will consider it to belong
to VLAN 1 and will bridge it accordingly. So, care needs to be taken when deciding which VLAN will be the native VLAN for your
trunk ports.
For a VLAN to work on a given switch, it must be created first. It is also a typical catch if you create a Switch Virtual Interface
(SVI; that is, a Layer 3 interface) for a given VLAN and the SVI does not come up. Verify the VLAN database (with show vlan)
and, if it’s missing, create it (setting a name is optional):
Click here to view code image
Switch1(config)# vlan 10
Switch1(config-vlan)# name marketingvlan
On the wireless side of things, lightweight access points require an access mode switchport unless FlexConnect local switching is
being used, which typically requires a trunk mode switchport because you are likely to use more than one SSID/VLAN (but it’s not
a hard requirement otherwise). Autonomous access points support both; it all depends on how many VLANs you configure the
access point to support.
53
||||||||||||||||||||
||||||||||||||||||||
Command Purpose
switch# show interface Displays all active trunk ports, their native VLANs, and VLANs currently active on them
trunk
Shows the VLAN database with all the VLANs existing on that particular switch, along with the ports
switch# show vlan
where they are active
Private VLANs
You can configure private VLANs to further isolate subdomains in a given VLAN. When configuring a private VLAN on a
switchport, the devices behind that port will be able to communicate only with the gateway and not spread Layer 2 broadcasts to
other ports on that switch in the same VLAN. It is also possible to carry the private VLAN information between several switches
supporting it, to create a subdomain within a given VLAN where devices can communicate directly at Layer 2 (those devices will
have to use the gateway for outside communication, though). There will be a mapping between a primary VLAN (a VLAN as we
have defined it so far) and secondary VLANs (private VLANs) that will exist within that VLAN on switches supporting this.
There are two types of private VLANs: isolated and community. An isolated secondary private VLAN can only communicate
toward the primary VLAN (and thus its gateway). A community secondary private VLAN can communicate to other hosts in the
same secondary VLAN as well as the primary VLAN, but cannot communicate to other secondary VLANs. A PVLAN port can be
configured in promiscuous mode or host mode. Promiscuous mode ports will allow communication from several (defined)
secondary and primary VLANs. Host mode ports will allow traffic only from specific secondary VLANs to promiscuous ports or
host ports in the same community PVLAN. Figure 2-2 illustrates the host port versus promiscuous ports behavior difference.
54
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figure 2-2 A Promiscuous Port for the Uplink and Two Hosts Connected to Host Ports
The figure shows a switch connected to an uplink through a promiscuous port. The port allows unidirectional traffic from
the switch to the uplink. The switch also connects to two remote hosts. The host ports, however, do not allow direct
communication between the hosts.
Private VLANs are useful when you want to segregate devices but still have to use the same VLAN (and therefore subnet and SVI).
In the next example, we are configuring VLAN 10 to be the primary, and within it, we will have secondary VLAN 200 in
community mode and 300 in isolated mode. Port Gig0/1 will be set in promiscuous mode and will allow traffic from both private
VLANs 200 and 300 to flow. Figure 2-3 illustrates the community mode behavior.
55
||||||||||||||||||||
||||||||||||||||||||
Command Purpose
switch# show vlan Displays all the private VLAN information along with their primary VLAN mapping and active ports
private
Shows the VLAN database with all the VLANs existing on that particular switch along with the ports
switch# show vlan
where they are active
As we already briefly mentioned, a well-managed network only allows for the needed VLANs on any link, to prevent unrequested
broadcasts from spamming your network unnecessarily. However, VLANs must exist in the VLAN database of all the switches they
will cross. It is easy to envision how painful the addition of a new VLAN or subnet will be. You create a VLAN on a switch, map a
switchport to it, allow it on your uplink trunk, and you think you’re done for the day—only to realize later that traffic is not passing
further down the network because you did not create that same VLAN on another switch that is on the traffic path.
This is where VLAN trunking protocol (VTP) comes to the rescue. The following explanations (unless specifying the particular
version) focus on VTP version 2. We also cover the differences with VTP version 3 right after. One of your switches will function
as a single source of truth and will update other switches in the VTP domain about the VLANs in operation. The domain is a group
of switches sharing VLAN information under a 32-character identifier. The switch operating in server mode can add, delete, or
rename any VLAN, and the configuration will be saved in the NVRAM. In client mode, the switch will receive its VLAN
information from the VTP server and will use this for its VLAN database. The administrator will not be allowed to make
modifications to the client switches VLAN database. One last VTP mode is the transparent mode, in which the switch does not
participate in VTP (that is, does not “install” the VTP information passed in its database) but will allow the propagation of that VTP
information to switches further down the path. In transparent mode, the administrator can make changes to the VLAN database on
that transparent mode switch. These modes are illustrated in Figure 2-4.
56
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Command Purpose
switch# show Displays all the interfaces of the switch and whether VTP is enabled for those interfaces (enabled by default on
vtp interface all interfaces; you can do “no vtp” on a given interface to disable it there)
switch# show Shows all VTP-related information (domain, version, mode, configuration revision)
vtp status
switch# show Displays information about all VTP version 3 devices in the domain
vtp devices
If a loop exists in a network in such a way that a frame can be received by a device after it sent that same frame, all hell breaks
loose. This would happen (if there was no spanning tree) as soon as more than one single link exists between two given devices in
the network. It would cause not only duplicated frames and out-of-order packets, but also switches would learn the same MAC
address alternating between different ports (also referred to as “flapping”). The loop would also cause endless traffic as broadcasts
(or frames sent to multiple destination ports) would create traffic that never stops until its time to live (TTL) expires (if there is one;
not all frames have a TTL).
The purpose of the Spanning Tree Protocol (STP) algorithm is to form a tree with the network topology. There is one root node, and
from there, only leaves: there are no more than a single path to any leaf, and all leaves can reach out to each other if going back
through the root and the whole structure is loop free.
This root node, called the root bridge (because switches are bridges originally) is elected based on the Bridge ID (BID), which is a
mix of a 2-byte priority field combined with the MAC address. In STP, the lower value is preferred to become the root bridge. In a
default configuration, the priority field is 32768 and is the same on all switches. The root is therefore chosen solely based on the
lowest MAC address. Interfering with this election process is as simple as lowering the priority value on the switch you want to
become root. Each switch will calculate the path cost to the root through all their possible ports. If only one port leads to the root
bridge, it will be elected the root port for that switch; if more than one port leads to the root, then the one with the shortest (that is,
lowest cost) will be chosen as the root port. A specific cost is associated to each link bandwidth (a 10 Gbps link has much smaller
cost than Fast Ethernet, for example). In case of identical path cost, the lowest port ID is chosen. All other ports leading to the root
(apart from the root port) will be put in blocked state to avoid loops.
Each switch sends STP messages called BPDUs as a Layer 2 multicast. Ports connecting to end devices do not receive BPDUs;
therefore, the switch knows there is no path to the root through those, and they can be in forwarding state.
The various STP states are the following:
Blocking: A port is always in blocking mode when it comes up (to avoid issues), and it stays in blocking state if the switch
detects it leads to the root bridge but is not the most optimal path.
Listening: When a port is in listening state, it listens for other switches or bridges. It does not send anything; it only listens.
Learning: The switch keeps listening for other bridges but can also learn MAC addresses on that port.
Forwarding: Normal operation mode. Data and BPDUs are passed through the port.
The main STP timers are the Hello timer, the Maximum Age, and the Forward Delay. The Hello timer means that the switch will
send a BPDU every 2 seconds by default. The max age of 20 seconds by default determines the time for which the port is kept in a
blocking state before listening. The forward delay of 15 seconds by default means the port will stay for 15 seconds in the listening
state before moving to the learning state, and the same amount of time between the learning state and the forwarding state.
Technically, this means that a port will not be forwarding traffic for 30 seconds after it is brought up.
Similar to the states, there can be three port types that STP will set on a given switch:
58
Technet24
||||||||||||||||||||
||||||||||||||||||||
Alternate (non-Designated): This port is blocked. It is a suboptimal path to the root. In case of failure of the root port, one of
the alternate ports will become the root port.
Figure 2-5 illustrates the different STP port types.
The figure illustrates the three different STP port types: Root port, designated port, and alternate port. The root port from a
switch connects to the root bridge via a designated port. The root bridge connects to the root port of another switch via a
designated port. This switch connects to the root port of another switch. Also, an alternate port exists between this switch
and the first switch. A cross mark indicates that the port is not chosen and should be closed down.
The only device that doesn’t have any of its ports in the root status is the root bridge.
Rather than modifying the priority of the bridge ID to influence the root bridge election, you can use commands to do it for you:
Click here to view code image
Switch1(config)# spanning-tree vlan X root primary
Switch2(config)# spanning-tree vlan X root secondary
These commands influence the priority so that Switch1 will lower its priority to be the root when it is online, and Switch2 will
become the root if Switch1 is not present. They are useful in making sure your backbone, or most powerful switch, is the root rather
than a smaller access switch. In case you want to set priorities manually, you can use spanning-tree vlan <vlan id> priority
<priority value>, but bear in mind the root commands are macros and don’t guarantee the switch will always be root regardless of
what further priorities show up on the network.
There are also situations where a device has two or more uplinks to interconnected backbone switches, and you want to determine
which link will be in the forwarding state and which one will be blocked, rather than letting STP decide.
Click here to view code image
Switch1(config)# interface Gig0/1
Switch1(config-if)# spanning-tree port-priority 0
Switch1(config-if)# interface Gig0/2
Switch1(config-if)# spanning-tree port-priority 240
The lower the port priority, the better. In the previous example, it means that port Gig0/1 will be forwarding rather than Gig0/2 if
59
||||||||||||||||||||
||||||||||||||||||||
Commands Purpose
show spanning-tree active Displays spanning tree information on active interfaces only.
show spanning-tree detail Displays a detailed summary of interface information.
show spanning-tree vlan vlan-id Displays spanning tree information for the specified VLAN.
show spanning-tree interface interface-id Displays spanning tree information for the specified interface.
show spanning-tree interface interface-id
Displays spanning tree portfast information for the specified interface.
portfast
Displays a summary of interface states or displays the total lines of the STP state
show spanning-tree summary [totals]
section.
show spanning-tree blockedports Displays all the alternate ports that are blocked currently.
We have only covered basic spanning tree in this section so far. Historically, many devices have been running Per-VLAN Spanning
Tree (PVST) or variants of it, such as Rapid PVST. With such a method, one completely separate instance of the Spanning Tree
algorithm runs on each VLAN the switch knows. Therefore, from the command spanning-tree vlan 30,40 root primary, you can
figure out that there can be different root bridges in each VLAN and that a different election and different tree is built for each
VLAN in the network, which can be very resource-consuming if you have many VLANs in your network.
Rapid PVST is a backward-compatible evolution of PVST that allows for a much faster convergence (within 1 second, compared to
30–50 seconds with the standard PVST).
The first and most important STP optimization command is spanning-tree portfast. This command is to be typed on edge ports
only, where no loop can happen and only client devices connect. A link failure on such a port should definitely not trigger any STP
topology changes. When the command is configured, the port is immediately moved to the forwarding state when it comes up. This
is a best practice to configure on ports (in switchport access mode) where unified access points in central switching are connected.
Access points have only clients connecting to them; they should never receive BPDUs over the air and will not cause any STP
topology changes. Therefore, this command allows AP switchports to immediately come up and into the forwarding state. A
variation of it is spanning-tree portfast trunk. Whereas a trunk typically indicates a connection to another switch, it can also be
used for access points in autonomous modes or FlexConnect local switching. In this case, the spanning-tree portfast command will
have no effect, and you must use spanning-tree portfast trunk instead because the switchport is in trunk mode.
BPDU Guard is a good complementary measure for portfast ports. When enabled, BPDU Guard shuts down the port (technically it
moves it to err-disabled, and you can configure recovery options) when it receives a BPDU. It is a secure response to an invalid and
unexpected event. Always keep in mind that portfast ports are supposed to be connected to end devices and should not be used to
connect a switch, because this would create a loop (since the portfast port is moved to forwarding state instantly). In such a
situation, BPDU Guard will prevent this from happening by shutting down the port, as illustrated in Figure 2-6. When enabled
globally, BPDU Guard will apply to all interfaces with portfast configuration.
60
Technet24
||||||||||||||||||||
||||||||||||||||||||
61
||||||||||||||||||||
||||||||||||||||||||
An evolution of Rapid PVST is Multiple Spanning Tree (MST). Having one instance of STP per VLAN is very resource consuming,
and MST solves this by having one MST instance run for several (typically an unlimited amount of) VLANs at a time. MST also
allows for multiple forwarding paths for data traffic and load balancing. MST is backward compatible in a network with devices
doing PVST or Rapid PVST. You can change the spanning tree mode with the command spanning-tree mode mst.
Switches will form an MST region and participate together if they have the same VLAN-to-instance mapping, the same
configuration revision number, and the same name. A VLAN can belong to only one MST instance (to prevent conflicting
decisions).
Click here to view code image
Switch1(config)# spanning-tree mst configuration
Switch1(config-mst)# instance 1 vlan 5,10-20
Switch1(config-mst)# name region1
Switch1(config-mst)# revision 1
Switch1(config-mst)# exit
Switch1(config)# spanning-tree mode mst
Switches will start the MST instance as soon as the spanning-tree mode mst command is entered.
Commands will be similar to PVST; for example, spanning-tree mst 1 root primary will configure the switch to be the root bridge
in all the VLANs covered by instance 1. Similar commands exist to other modes and are preceded by the MST instance ID. You can
also configure several MST instance IDs by using commas or hyphens.
We already covered that access points should always be on switchports configured with spanning-tree portfast. WLCs don’t
participate in spanning tree or send BPDUs. Because they should never create a loop (whether APs are in local mode or
FlexConnect), and because it is a front end for clients and no other network devices, it is recommended to set the WLC port as a
portfast trunk as well. Note, however, that there may be an exception revolving around Mesh Ethernet bridging or workgroup
bridging where you may end up with a switch being connected behind a wireless client. In this particular instance, it is up to the
administrator to make sure there will not be a loop (that is, the remote bridged site should not have a wired connection to the root
side) and that BPDUs are not sent over the air.
EtherChannel
EtherChannel, also referred to as portchannel, is a widespread technology in wireless networks. It answers several questions:
How can I leverage an existing infrastructure to get more bandwidth on a link between these two devices without upgrading to
the next Ethernet standard? (Two times 1 Gbps links is sometimes cheaper or more easily implemented due to hardware
limitations than a single 10 Gbps link or, similarly, two times 10 Gbps rather than a single 40 Gbps, for example, and might just
fit the need.)
How can I get more reliability in case a link goes down due to port or cable failure?
The now legendary Cisco 4404 WLC had four 1 Gbps ports at a time when 10 Gbps was still expensive and not particularly widely
available on core campus switches. Today, the 8540 WLC has four 10 Gbps ports for the very same reasons. (10 Gbps has become
more affordable and widespread, whereas 40 Gbps is not quite there yet.) On top of the increased bandwidth, EtherChannel also
provides link redundancy: when one of the links forming the EtherChannel goes down, the others keep forwarding, and the only
62
Technet24
||||||||||||||||||||
||||||||||||||||||||
If you don’t use EtherChannel and set up several physical links between the same two network devices, spanning tree will do its job
and block all but one link to avoid loops, as shown in Figure 2-9. There is no increased bandwidth involved because only one link is
used at a time, and the spanning tree algorithm will be the one deciding which other link will come up after the active link goes
down. The redundancy is, therefore, slightly less real-time because it’s another link that has to come up. With EtherChannel, you
are grouping physical interfaces together, therefore creating a virtual portchannel interface that will represent all the links as a
single one from that point on. This single virtual portchannel interface means that for STP, all links participating in the portchannel
are now seen as a single link and therefore are set to forwarding or blocked all together as one. It also means that you can (and
actually must) from there on configure all those links only through the virtual portchannel interface rather than through the specific
physical interfaces. The portchannel interface configuration will be applied to all ports participating in the portchannel bundle.
63
||||||||||||||||||||
||||||||||||||||||||
There are a few restrictions though. EtherChannel can only be configured between a maximum of 8 ports of the same speed and
technology (all GigabitEthernet or all TenGigabitEthernet, but no mix-and-match). Each end of an EtherChannel link must also be
configured in the same way.
A careful reader will immediately ask how loops are prevented, because all the physical links constituting a portchannel are up and
forwarding at the same time, and STP sees them as only one link. The answer is the load balancing algorithm. The switch(es) where
EtherChannel is configured will use a configurable algorithm to make sure packets of the same flow will always go through the
same physical port. This prevents out-of-order packets or fragmentation issues in an easy and practical manner. A classical method
for wireless networks is to declare that all packets from the same source and destination IP pair will go through the same link. This
means that a specific access point will always send its traffic through the same link when sending to the WLC, but another access
point might use another physical link. This is completely transparent to the end devices because only the two devices participating
in the EtherChannel bundle are aware and must agree on this method.
You have three methods of configuring an EtherChannel:
By using PAgP negotiation protocol
By using LACP negotiation protocol
By turning it always on without negotiation
The same method should be used on both ends of an EtherChannel in all cases. PAgP is a Cisco proprietary protocol that will verify
whether the parameters are identical on both ends before enabling the EtherChannel. This is configured with the command
channel-group <etherchannel number> mode desirable (where X is to be replaced with the EtherChannel group number). PAgP
is not supported with WLCs.
LACP is an IEEE specification that allows a switch to negotiate an automatic bundle by sending LACP packets to the other side.
This mode can be enabled by using channel-group <etherchannel number> mode active. It is not supported for use with WLCs
but is supported for use with select 802.11ac Wave 2 access points having an AUX port.
When configuring with channel-group <etherchannel number> mode on, the EtherChannel is established without any form of
negotiation. This mode is the only one that can be used with WLCs.
The configuration guidelines are as follows:
EtherChannel support: All interfaces must support EtherChannel. They can be of different media type and on different
modules but on the same switch, even if virtual, such as in a VSS.
Speed and duplex: All interfaces configured must operate at the same speed and duplex mode.
VLANs: All interfaces configured in the EtherChannel must be assigned to the same VLAN or must be configured as trunk,
before joining an EtherChannel. If trunk, they must support the same range of VLANs.
Example 2-3 shows how to configure interfaces Gig0/1 and Gig0/2 into a LACP portchannel allowing VLANs 1 to 10. After the
portchannel is created, further configuration changes will happen directly in the portchannel interface.
Example 2-3 Configuring LACP-enabled Portchannel Interface
Technet24
||||||||||||||||||||
||||||||||||||||||||
Command Purpose
switch# show interface port-channel channel-number Displays the status of a portchannel interface.
switch# show lacp { counters | interface type slot / port | neighbor Displays LACP information.
| port-channel | system-identifier }
Displays the parameters that must be the same among the
switch# show port-channel compatibility-parameters
member ports to join a portchannel.
switch# show port-channel database [ interface port-channel Displays the aggregation state for one or more portchannel
channel-number] interfaces.
switch# show port-channel load-balance Displays the type of load balancing in use for portchannels.
switch# show port-channel summary Displays a summary for the portchannel interfaces.
Anticipating further chapters, let’s underline that if you are using LAG on a WLC, you should have only one interface marked for
“Dynamic AP management,” but if you don’t use LAG, you should have one interface with “Dynamic AP management” enabled
on each physical port of the WLC.
It is also possible to configure LAG between a switch and a Wave2 access point (provided it has an AUX port) like the 1850, the
2802, or the 3802 (because they have an AUX port). The problem would be that because all the traffic is tunneled to the WLC
through the CAPWAP data tunnel, it would be hard to load balance anything between the two ports. This is why, when enabling
LAG, those access points establish a second CAPWAP data tunnel to the WLC using another source port. The switch can then use
the command port-channel load-balance src-dst-port as a load-balancing mechanism to load balance the traffic between the two
AP ports. This, however, is not yet supported in FlexConnect local switching. If the switch does not support Layer 4 (port) load-
balancing, there will be redundancy, but all the traffic will go through a single port.
After the AP registers to the WLC, run the following commands from the WLC command line:
Click here to view code image
config ap lag-mode support enable
(This will NOT result in a reboot of the APs that support LAG)
This command enables the support for AP LAG mode globally on the WLC. To check the current status of the AP LAG mode
support on the WLC, run the command show ap lag-mode. To disable support for AP LAG mode, use config ap lag-mode
support disable (this will result in a reboot of all the APs that support LAG).
65
||||||||||||||||||||
||||||||||||||||||||
Cisco Discovery Protocol (CDP) is a Layer 2, media-independent and network-layer independent protocol that runs on Cisco
devices and some third-party devices as well (although it is Cisco proprietary) that allows devices to learn what is directly
connected to them. Each device configured for CDP periodically sends advertisements to the multicast MAC address
01:00:0c:cc:cc:cc. By listening for this MAC address, the device will also learn about CDP-enabled devices that are directly
connected to it. CDP is not forwarded by Cisco devices; therefore it is only point-to-point and does not travel through the network.
CDP information includes the following:
Cisco IOS version running on Cisco devices
Hardware platform of devices
IP addresses of interfaces on devices
Locally connected devices advertising Cisco Discovery Protocol
Interfaces active on Cisco devices, including encapsulation type
Hostname
Duplex setting
VLAN Trunking Protocol (VTP) domain
Native VLAN
CDP allows for detection of native VLAN mismatch on trunk ports and is very helpful in troubleshooting to understand the physical
network topology.
Link Layer Discovery Protocol (LLDP) is a similar standard protocol that will perform the same kind of functions as CDP but will
bring compatibility with third-party devices that are more likely to support LLDP than CDP. LLDP-MED is a Media Endpoint
Device extension for LLDP, which adds more capabilities with regard to power management and network policies.
CDP neighbors can be verified both on the switch or on the AP with the show cdp neighbors command. On a switch, you can
enable CDP globally with the configuration-level command cdp run. It is then enabled by default on all interfaces. You could
disable it on a given interface with no cdp enable under that specific interface. LLDP works in a similar manner and can be
enabled with the global command lldp run. You can then enable it for a specific interface with lldp transmit and lldp receive
commands. show lldp neighbors will give you the LLDP neighbor. Example 2-4 shows the CDP neighbor output showing an
access point along with the power levels it requested (refer to the next section for PoE with CDP):
66
Technet24
||||||||||||||||||||
||||||||||||||||||||
Command Purpose
WLC> show cdp Displays the list of WLC CDP neighbors.
neighbor
WLC> show ap The WLC also receives information from the APs with regard to their CDP neighbors. This is useful to verify
cdp neighbors all on which switch(port) an AP is connected, straight from the WLC command line.
Power over Ethernet is a very handy technology for powering access points, because it allows you to run only one network cable to
the AP location, instead of an extra power cable (and power supply, which would need to be tied up properly and which might heat,
and so on). Things were a bit more complicated in the past with prestandard technologies, but for the purposes of this book, let’s
focus on the 802.3af PoE standard that allows up to 15 watts and the 802.3at standard (often referred to as PoE+) that allows up to
30 watts to the device. Some outdoor APs require a bit more than 30 watts and have to rely on UPoE, which can provide up to 60
watts, but that is not yet an IEEE standard (at the time of this writing and will be superseded eventually by 802.3bt, which promises
90 watts). In any case, at present, most APs don’t require that much power. Each AP has different power requirements:
A 3600 will operate at full capacity with 15 watts 802.3af PoE.
A 3700 will require PoE+ to fully operate because it consumes up to 16.8 watts. However, it can operate in “medium power”
with a standard 802.3af (15 watts) and will then power off one antenna (3×3 MIMO instead of 4×4).
A 3800 will require 802.3at to operate, with no “medium power” available at all.
Those are just examples of how things differ with each AP model. Some APs will be able to boot when given insufficient power
(802.3af instead of 802.3at, for example) but will keep the radios completely down, allowing you to spot the problem and remediate
it.
PoE is most practical when the switch supports it and can deliver the power to the device connected without any form of particular
intervention. When a cable is plugged in, there is a physical detection mechanism (based on impedance detection) that can figure
out whether the connected device supports PoE. This detection has to happen when the device is still powered off and is required to
prevent the switch to send power to a device not supporting power on the Ethernet port (which would otherwise most probably
burn it). There are predefined watts requirement “steps” that can be detected this way. After the device has booted, it is also
possible for a more granular power negotiation to occur. This can take place through CDP or LLDP (LLDP is not Cisco
67
||||||||||||||||||||
||||||||||||||||||||
68
Technet24
||||||||||||||||||||
||||||||||||||||||||
IP Layer Refresher
After reviewing protocols at the switching layer, we will not move into the routing layer, because not a lot of it is present in the
CCIE Wireless exam. But a refresher of IPv4 and IPv6 is in order because we have both worlds overlapping to support the wireless
network.
IPv4
It would be too ambitious for this book to try to cover all IPv4 and IPv6 right after, so let’s call this a refresher instead. You might
have forgotten or overlooked some points, and we will try to go through the main traps and pitfalls for an expert wireless engineer
who may tend to overlook some IP details.
IPv4 addresses are very limited, and it may be interesting to review the special and reserved address ranges. The private ranges,
which do not route on the Internet, are 10.0.0.0 to 10.255.255.255 (/8 subnet), 172.16.0.0 to 172.131.255.255 (/16), and
192.168.0.0 to 192.168.255.255 (/24). Anything starting with 127 (127.0.0.0 /8) depicts a loopback address and thus never goes on
the network (a loopback is an interface on a device that points back to itself). The range called APIPA is 169.254.0.0/16 and is a
link-local address range, which means those addresses are valid on point-to-point links but do not route. The APIPA range is
famous on client devices when the DHCP process is failing; that is, many client operating systems will automatically pick an IP
address in the APIPA range (but will have no connectivity to the network with that), so if you see this one in the CCIE exam, it
typically means that your client could not obtain a DHCP IP address. 192.0.2.0/24 are 254 special purpose IP addresses where, for
example, we now recommend to use 192.0.2.1 for the virtual IP of a WLC so that it does not route anywhere on the network
outside of the WLC. 224.0.0.0 to 239.255.255.255 are reserved for multicast, and IP addresses above 240.0.0.0 are reserved for
future use. There are a couple more specific ranges, but they are not so useful to remember for the scope of the CCIE Wireless
exam.
For a device to directly talk to another device, they must be in the same subnet range (defined by the network IP address and the
subnet mask combination). The station that wants to transmit will send an Address Resolution Protocol (ARP) request to figure out
the MAC address of the destination device, which, in turn, will send a reply. At this point, the transmitter knows both the IP and
MAC binding of the destination and can then transmit. If the transmitter realizes that the destination IP is not in its subnet, it will
have to send the packet to its gateway for the packet to be routed. If the device hasn’t contacted its gateway yet, it will also have to
ARP for that gateway in its subnet to figure out its MAC address. That gateway will have to consult its routing table to know where
to send the packet (directly to destination or to another router/gateway).
A concept that is critical to understand for the CCIE Wireless exam is whether your switch is Layer 2 or Layer 3; that is, if it is
routing. Nowadays, what is called a Layer 2 switch is a switch with only one IP address (for management) but possibly supporting a
lot of VLANs. That switch will forward traffic only within the same VLANs and will not perform any routing. For a device to
qualify as being a gateway, it needs routing to be activated and, therefore, will typically need at least two IP addresses to be present
in more than one subnet. Be careful because it is also possible that a switch has several IP addresses but still has no routing
activated, although this is a bit unusual.
Some old timers may have the reflex to check the show ip route command output to see if routing is enabled on the switch, but in
recent IOS versions this output can be confusing and show you outputs that look like it is routing even when it’s not (see Example
2-5). Therefore, the only real way of checking whether routing is enabled is to verify whether ip routing has been enabled in the
configuration.
Example 2-5 Routing Table Output When Routing Is Disabled Globally
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
IPv6
IPv6 is like IPv4 but uses 128 bits addressing instead of 32 bits. Well, not quite, but that’s a start to begin describing the
differences. An IPv6 address is written with colons and using hexadecimal characters (to help make it shorter). An example is
2001:0db8:ac10:fabc:0001:0003:0004:0005. Because it clearly looks cumbersome to write, there is a common notation that accepts
that leading 0s are not written. With this in mind, the previous address would become 2001:db8:ac10:fabc:1:3:4:5, which, though
still hard to memorize, is clearly easier on the eye. It is important to underline that we are talking only about leading 0s. If we look,
for example, at the second quartet (hextet) of that IP, here “db8” must translate only to “0db8.” If it was “db80,” we could not
write it “db8” because it would create confusion. The other notation trick to remember is that, once per IP address, you can group a
series of contiguous 0s with “::”. For example, the famous loopback 127.0.0.1 becomes ::1 in IPv6. This means the full IPv6 for it is
0:0:0:0:0:0:0:1 (we saved you the quadruple zeros). More examples of this notation follow in the upcoming paragraphs.
What IP addresses are special in IPv6? Routable Internet unicast IPs are 2000::/3, which is 2000:0:0:0:0:0:0:0 to
3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff (notice how subnet masks are harder to map if you are not used to them, but because IPv6 uses
hexadecimal, you need to think binary all the way). That makes a lot of routable IP addresses and still leaves a lot of IPs for
reserved special uses. Local addresses are fe80::/10, so will often start with “fe80” but technically, they are “fe80” to “febX”
because the subnet mask stops after 10 bits. The local addresses are a lot like the IPv4 APIPA range, because they are valid only on
the local link and will not be routed. They are used for devices directly connecting to each other and willing to exchange data
without a DHCP server, or at least without caring about what address the DHCP server assigned to them. FC00::/7 depicts unique
local addresses intended for local communications. They are the equivalent of 10.0.0.0 or 192.168.0.0 subnets in IPv4. Multicast
addresses start with ff0X, where X is assigned by the IANA; for example, ff02::9 is the RIP router IP address, ff02::1:2 (which is
71
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
In the CISCO WLC webpage, the Controller option is selected. In the content pane, the Edit within the RA Throttle Policy
is displayed. The list of details as follows, Enable RA Throttle Policy, Throttle Period (10-86400 seconds), Max Through
(0-256), Interval Option, Allow At-least (0-32), and Allow At-most (0-256) are to be entered.
The last major IPv6 configuration page of the WLC is the Neighbor Binding page, which allows tweaking the neighbor table cache
on the WLC. As shown on Figure 2-13, you can adjust the Down Lifetime there, which is the timer specifying for how long the
entry will stay in the table if the interface goes down. There is the Reachable Lifetime setting, which specifies how long an IPv6
address is marked as active after traffic was received from it and after which it will be marked stale. The Stale Lifetime is the
amount of time the address will stay in the cache after no traffic was seen from them during the entire reachable lifetime.
74
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the COSCO webpage, the Controller option is selected. Under Neighbor Binding in the content pane, the Down Lifetime
(0-86400 seconds), Reachable Lifetime (0-86400 seconds), Stale Lifetime (0-86400 seconds) are entered. The Unknown
Address Multicast NS Forwarding and NA Multicast Forwarding drop-down box are selected.
With regard to configuring IPv6 addresses on the WLC itself (so far, we explained this is not needed for clients to be IPv6
enabled), the management interface accepts one IPv6 address. Dynamic interfaces cannot be configured with IPv6: only their
VLAN matters (because they will bridge IPv6 traffic to an IPv6-enabled VLAN, which will take care of the address assignment),
and there should not even be a need to configure IPv6 addresses on dynamic interfaces because their main purpose is DHCP relay
in IPv4 (which doesn’t apply anymore for IPv6). The service port can also be configured with an IPv6 address. The management
interface gateway must be configured with the link-local address (the one starting with fe80) of the next-hop router. This is a bit
counterintuitive compared to IPv4, where the interface IP and the gateway have to be in the same subnet, but in IPv6, because
interfaces have multiple addresses, the gateway is expressed with a link-local address, whereas the interface IP is expected to be a
global unicast address.
Access points will use any method to obtain an IP address (IPv4 or IPv6 or both). It is possible to configure a preference to tell the
APs to join the WLC through capwap-on-ipv4 or capwap-on-ipv6: either configured globally on the Controller page of the WLC
web interface or in the specific AP group. This is just a preference, so if you configure IPv6 as CAPWAP preferred mode, the AP
will still join through IPv4 if it cannot obtain an IPv6 address (or vice versa).
A multicast CAPWAP group can also be configured on the WLC to allow it to forward multicast traffic through IPv6 multicast.
Mobility can also happen through IPv6, as well as Syslog, NTP, and RADIUS. This section concludes with Table 2-7, which shows
a few useful commands to look at the IPv6 configuration on the WLC.
Table 2-7 IPv6-Related Troubleshooting Commands on the WLC
Command Purpose
WLC> show ipv6 neighbor- Displays the list of IPv6 neighbor bindings (IPv6 Mac address mappings).
binding summary
WLC> show ipv6 summary Shows the summary of all IPv6 configuration items of the WLC.
WLC> show network Shows the configuration items of the Controller web GUI page, which includes IPv6 multicast
summary configuration and CAPWAP prefer mode.
The ping command on the WLC accepts an IPv6 address (contrary to some client OS, where you
WLC> ping <ipv6 ip>
may have to use a separate command like ping6).
Multicast
The multicast concept applies to both IPv4 and IPv6—there will be differences in the protocols in use, but the concepts are
identical. Multicast is a vastly underappreciated and misunderstood technology. To make it as clear as possible, let’s mention use
75
||||||||||||||||||||
||||||||||||||||||||
76
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the Unicast mechanism, one multicast packet enters the Wireless LAN Controller. From the WLC, three CAPWAP
Unicast Packets are sent out to three different Lightweight Radio Access Points via CAPWAP tunnels. In the Multicast
mechanism, one multicast packet enters a WLC. From here, only one CAPWAP multicast packet is sent out to a
CAPWAP multicast group. The network replicates the packet as needed to different Lightweight Radio Access Points.
That multicast IP defined on the WLC will be used only for the IP header of the CAPWAP encapsulation and has nothing to do
with whatever is carried inside it (typically another multicast packet of whatever stream you are requesting). The WLC also offers
the possibility of configuring another multicast IP for mobility messaging, which will only be used to reach out to all other mobility
peers with a single packet when it comes to announcements that should be sent to all mobility peers anyway. That is unrelated to
whether you are allowing multicast traffic on your wireless clients and is a matter of efficiency when you have more than three
WLCs in a mobility relationship.
Let’s leave the wireless side a bit aside and talk about multicast in general. Imagine a Layer 2 segment where, by default, multicast
packets will be sent across all ports to all stations on that Layer 2 segment. This can be very aggressive in a network. Therefore,
IGMP is a way for clients or devices to request receiving a specific multicast stream. If we just rely on the clients sending these
IGMP registration packets, not much will change. If network devices implement what is called IGMP snooping, they will block
multicast packets from spreading to all ports and will take notes of which client is interested in which multicast stream. The network
device will then forward the multicast packets only to the ports leading toward clients that are interested in the specific stream. This
is where the efficiency kicks in. Before we dig further into IGMP, it is important to understand that IGMP will not play a role in
service discovery protocols. IGMP itself is using multicast with an IP range in the 224.x.y.z area, which will be forwarded even if
IGMP snooping is enabled (because those are announcement-based protocols and need to go through).
IGMP is a protocol that enables end hosts (receivers) to inform a multicast router (IGMP querier) of the end host intention to
receive a particular multicast traffic. So, this is a protocol that runs between a router and end hosts (it stays limited within a Layer 2
subnet and does not get routed) and allows the following:
Routers to ask end hosts if they need a particular multicast stream (IGMP query)
End hosts to tell or respond to the router if they seek a particular multicast stream (IGMP reports)
There are three versions of IGMP. IGMPv1 uses a query-response model where queries are sent to 224.0.0.1 (all-hosts) and
membership reports are sent to the group multicast address. IGMPv2 improves by adding the capability for a host to leave a
multicast group without having to time out. Leave-group messages are sent to 224.0.0.2 (all-routers) and group-specific queries are
introduced. IGMPv3 introduces source-specific multicast (the possibility to subscribe to a multicast group but only with selected
source IPs) and membership reports are then sent to 224.0.0.22. IGMP is carried directly over IP (IP protocol 2) kind of like ICMP
is. There are very few types of IGMP messages:
Membership queries are sent by hosts, and they specify within the IGMP packet which group IP they want to join, but that
multicast packet is sent to 224.0.0.1 (or .22 in IGMPv3) to hit the multicast router for the network (typically the device where
77
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Command Purpose
L3switch# show ip pim neighbor Displays the list of PIM neighbors discovered by IOS.
L3switch# show ip mroute Shows the multicast routing table.
L3switch# show ip rpf a.b.c.d Shows how multicast routing does the Reverse Path Forwarding for a given IP address.
L3switch# show ip pim interface Displays information about interfaces configured for PIM.
L3switch# show ip igmp snooping group Displays the IGMP groups.
All this explains how multicast works in an IPv4 network. Things are similar in IPv6 networks with the exception of IGMP, which
is too IPv4-specific. IPv6 relies on Multicast Listener Discovery (MLD), which is based on ICMPv6. MLDv1 has similar features
to IGMPv2, whereas MLDv2 is similar to IGMPv3. MLD is automatically enabled on IOS after you enable PIM6.
MLD has a “Multicast Done” message format that is sent when the multicast receiver stops listening to the mentioned IPv6
multicast stream (like IGMP Leave). It has a Multicast Listener query message type, issued by routers to discover whether anyone
is subscribed to a particular multicast address in the local-link network or a more general query to ask listeners what multicast
groups they are currently registered to. Finally, an unsolicited Multicast report message is sent by a node when it starts listening to a
particular multicast address. Reports are also sent in response to query messages.
Click here to view code image
Router(config)# ipv6 mld snooping
This command enables MLD snooping globally, but you also must enable it on the specific SVIs to operate at Layer 3 with the
following:
Click here to view code image
Router(config)# interface Vlan10
Router(config-if)# ipv6 mld snooping
Bonjour is an Apple service discovery protocol that locates devices and the services they offer on a local network with the use of
multicast DNS (mDNS) service records. The protocol works based on queries (“Who provides AirPrint service around here?”) and
advertisement (“Hey everyone, I’m an AppleTV, and I provide AirPlay services at this IP address with this name”). All those
packets are sent on multicast IP 224.0.0.251 or IPv6 FF02::FB on UDP port 5353.
As typically is the case with IPs in the 224.x.y.z range, the time-to-live (TTL) is set to 1 to make sure that routers will not route this
traffic globally (no point in the Internet knowing about your printer). Although this works great in home networks, it does not scale
well in enterprise networks, where multiple VLANs and subnets are used within the same building.
The WLC (more on this in Chapter 7) has a Bonjour gateway feature where the WLC will take note of all the services advertised in
all the VLANs that the WLC controls and will respond to queries coming in the same and/or other VLANs on behalf of the service
providers for the services that it has cached and are queried. This means that the multicast packets are not routed between VLANs,
but the WLC responds to queries in his VLANs and listens to advertisements too. This allows services to be available and
discoverable across VLANs without the multicast packets to route everywhere. Responses to service queries are unicasted back to
clients, and clients reach out to the service provider via unicast as well. This is why there is little multicast involved in this protocol
apart from the service discovery.
Services have very specific name strings in Bonjour. A few examples are the screen sharing using _airplay._tcp.local., Apple
printers using _printer._tcp.local., and universal printers using _universal._sub._ipp._tcp.local.
79
||||||||||||||||||||
||||||||||||||||||||
MAB is named that way because it started as a “bypass” of 802.1X authentication for devices that don’t support that protocol.
However, it is really something separate nowadays. The idea behind MAB is that the administrator configures specific ports for
MAB authentication, and those ports will not pass traffic when they come up until the device is authenticated. When the port
receives traffic from the device MAC address, it then asks the central RADIUS server (more on RADIUS in Chapter 5, “Wireless
Security and Identity Management with ISE”) it is configured for whether this MAC address is authorized.
The following configures a switch to enable the authentication process required for MAB:
Click here to view code image
Switch1(config)# dot1x system-auth-control
Switch1(config)# aaa new-model
Switch1(config)# ip device tracking
The following configures a switchport to do MAB for any device connecting to it:
80
Technet24
||||||||||||||||||||
||||||||||||||||||||
802.1X
802.1X (or dot1x as it’s regularly called) is a two-way authentication method that requires both the end devices (the RADIUS
server and the AP in our case) to authenticate and trust each other. The client (an AP in our case) will typically either use
credentials (username/password) or a certificate to authenticate itself.
If the AP has already joined the WLC and you want to configure dot1x authentication from then on (which implies that at this point
the switchport is not enforcing authentication yet), you can do so from the WLC web GUI. In the Global Configuration section of
the Wireless tab (as shown in Figure 2-15), you can configure a common set of username and password for every AP joined to that
WLC under 802.1x supplicant credentials. You can also make the credentials AP-specific by configuring them under the
Credentials tab of the specific AP configuration page, as shown in Figure 2-16.
81
||||||||||||||||||||
||||||||||||||||||||
In the screenshot, the Wireless tab is selected. On the left pane, All APs is selected under Access Points of Wireless
options. On the right pane, the Credentials tab is selected under All APs. The Credentials tab displays Over-ride Global
credentials checkbox under Login credentials. Over-ride Global credentials checkbox is selected with the username entered
as dot1xusername and eight digit password is entered for password and confirm password.
82
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the screenshot, the Wireless tab is selected. On the left pane, the Global configuration option is selected under Access
Points. Under the Global configuration, the LED State check box with Disable is shown in the drop-down under General
section. Under the CDP section, the CDP State check box is selected for Ethernet interface numbered from 0 to 4 and
Radio slot numbered from 0 to 2. Under Login credentials, the Username, Password, and Enable password textboxes are
shown. Under 802.1x Supplicant Credentials, the 802.1x Authentication check box is selected, the dot1xusername is
entered as Username with an eight-digit password is entered for Password and Confirm Password.
If your switchports are already configured for authentication, your new APs will not be able to obtain an IP address or join the
WLC at all until they are manually configured for credentials. You can do so with the following command:
Click here to view code image
LAP# capwap ap dot1x username <username> password <password>
IOS-based APs (802.11ac Wave 1 and before) require you to first type debug capwap console cli to configure the credentials.
83
||||||||||||||||||||
||||||||||||||||||||
Configuring ISE
More explanations will be given in Chapter 5 to configure ISE for dot1x or MAC authentication, but here are a few illustrations of
an ISE policy that will authenticate an AP using dot1x. We are configuring the switch as a AAA client in ISE on Figure 2-17,
configuring the authentication and authorization policies in Figure 2-18 and 2-20, verifying that EAP-FAST is allowed in Figure 2-
19, creating a user for the APs to use in Figure 2-21, and verifying that the authentication works successfully in Figure 2-22.
84
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figure 2-18 Authentication Policy Pointing Wired dot1x Authentication to the Default Policy and All Identity Stores
The Authentication tab is selected under the Policy options. The Authentication Policy displays the path for policy export
page. The Rule-Based radio button is selected within Policy Type. The MAB and Default checkbox is selected, the Dot1X
and Default checkbox is selected and highlighted, and the Default Rule (if no match) checkbox is selected.
Figure 2-19 Make Sure That the Default Network Access Allows for EAP-FAST Authentication
The Network Devices tab is selected under the Network Resources of Administration in ISE is shown. Under the Network
Devices in the content pane, the Name (mandatory), Description, IP Address (mandatory) are entered, Device Profile,
Model Name, Software Version drop-down boxes are selected. Under the Network Device Group, the Device Type and
Location are selected from a drop-down with Set to Default button shown beside. The checkbox for RADIUS
Authentication Settings is selected that enable authentication settings as Protocol, Shared Secret (mandatory) with Show
85
||||||||||||||||||||
||||||||||||||||||||
Figure 2-20 Authorization Policy Permits Access in Case the Identity Belongs to Identity Group AP
A screenshot shows the Policy tab selected in the Identity Services Engine. Under this, the Authorization tab is selected to
display the Authorization Policy. Several rule names, with their status, conditions, and permissions are shown. A specific
AP (APs_dot1.x) is set to PermitAccess if the condition is "APs and Wired_802.1X."
Figure 2-21 Create a User in the Identity Store with the Credentials Configured for the AP on the WLC
In the screenshot, on the Administration page, the path, Identity Management, Groups is selected and displayed. The left
pane lists the Identity Groups, as collapsible sections. Two sections are listed: Endpoint Identity Groups and User Identity
Groups (selected). The content pane shows the User Identity Groups of AP. It has two text fields: Name and Description,
along with Save and Reset buttons. Below this, is a table titled Member Users, with column headers Status, Email,
Username, First Name, and Last Name. Each row in the table has an individual checkbox for selecting that particular row.
The table has options to add, delete, and filter data.
86
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figure 2-22 A Successful AP dot1x Authentication as Seen in the ISE Live Logs
In the screenshot, on the Operations page, the path, RADIUS, Live logs is displayed. The content pane shows a summary of
the number of cases with Misconfigured Supplicants, Misconfigured Network Devices, RADIUS Drops, Client Stopped
Responding, and Repeat counter. Below is a table with column headers Time, Status, Details, Repeat, Identity, Endpoint
ID, and so on. A few of the fields in the table are hyperlinks. The table has options to Refresh, Reset Repeat Counts,
Export, and Filter.
Table 2-9 is useful for troubleshooting dot1x authentication on a port but also for MAB use cases (such as we covered in the
previous section) because both are authentication methods for switchports.
Table 2-9 Useful Switch-Side Troubleshooting Commands for Use in Troubleshooting Authenticated Switchports
Command Purpose
switch# show Displays the list of authentications that are taking or have taken place (and are still active) on all switchports.
authentication When specified for a MAC address or interface, the command lists all the authentication details of that session
session [interface (which method was used, client MAC address, current status, and attributes being applied, such as ACL or
int-number] VLAN).
switch# show
access-session This command is nearly identical to the previous, but on some switch platforms or depending on configuration
[interface int- show access-session is used instead of show authentication session.
number]
switch# show dot1x Displays the list of clients connected to that interface, their current status, and the method used to
interface [int-
authenticate, as well as the interface timers and settings pertaining to dot1x.
number] details
switch# debug Starts a debug of the dot1x process.
dot1x all
switch# debug mab Starts a debug of the MAB process.
switch# debug Starts a debug of the overall authentication process.
authentication all
When a switch is configured for authentication port-control auto, it will start authenticating when a MAC address is seen on the
port, but what if multiple devices and MAC addresses are connected?
In single-host mode (command authentication host-mode single-host on the switchport), the switch will tolerate only one MAC
address to be present. If the client is replaced with another client (new MAC address), a new authentication will have to take place
for that new MAC address, but only one at a time is tolerated.
Multi-domain authentication is used (authentication host-mode multi-domain) when an IP phone is connected to the same
switchport as a data client. The RADIUS server will then return particular vendor-specific attributes (VSA) to place the IP phone in
the voice VLAN after a successful authentication; this then leaves room for one more MAC address (typically a PC) in the data
VLAN. This mode allows for only two MAC addresses to be present, and one of them must be identified as a voice VLAN type by
the RADIUS server (through the policies configured). Both devices (phone and PC) will have to go through authentication.
Multi-host authentication (authentication host-mode multi-host) is used when several data clients are connected to the same port.
87
||||||||||||||||||||
||||||||||||||||||||
We already covered one particularity of FlexConnect APs operating in local switching; that is, client MAC addresses will appear on
the switchport where the AP is connected and will create many authentication sessions. In this case, multi-host mode could be a
workaround, because if the AP successfully authenticates, all client MAC addresses will be automatically approved as well. But this
does not cover another problem: FlexConnect APs in local switching typically operate on trunk ports when they service WLANs in
different VLANs and, by default, dot1x authentication occurs only on access mode ports. There is, however, a solution: if the
RADIUS server returns the Cisco VSA device-traffic-class=switch, then the switchport will automatically be configured as trunk.
This is automatically done when selecting “NEAT” in the ISE authorization result. The switch configuration does not differ a lot
but, in this case, aaa authorization network needs to be configured to apply the attribute returned by ISE. The debug debug
authentication feature autocfg all is specific to this scenario and will show that the authorization result makes the switch enforce
a trunk port configuration, as shown in Example 2-7.
Example 2-7 Debugging Output of a Trunk Switchport Configured for dot1x NEAT
88
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figure 2-23 ISE Authorization Policy Returns NEAT Attribute for APs on Trunk Port
In the screenshot, on the Policy page of the Cisco web interface, the path Policy Elements, Results is selected and
displayed. From the navigation pane along the left, Authorization Profiles from the section Authorization is selected. The
content pane shows the fields required to add a new authorization profile. The fields are Name - a text field, Description - a
text field, Access Type - a drop-down field, Network device profile - a drop-down field, and three checkboxes for Service
Template, Track Movement, and Passive Identity Tracking. Below this, is a collapsible section titled Common Tasks. It has
a list of four checkboxes to select among Assess Vulnerabilities, Reauthentication, MACSec Policy, and NEAT. NEAT is
selected.
This feature works best with multi-host mode for wireless clients to not retrigger authentications on the switch.
SNMP
Simple Network Management Protocol (SNMP) is the standard in network management (although many protocols, such as
NETCONF/Yang, are knocking at the door to replace and complete it). SNMP exists in three versions. There are virtually no
reasons to use v1, so we will focus on v2 and v3, which are the most widely used. SNMP is the protocol, running on UDP, used to
poll a remote device about its current status, configuration, and/or health. This data (status, configuration, and so on) is stored on
the device in a standardized database called the Management Information Base (MIB). Basically, for every configuration line you
enter, the configuration part of the MIB gets written accordingly. For every statistic or counter that the device is measuring, the
relevant part of the MIB is also updated, and as such the MIB becomes the real-time database of the device. We first need to
understand how this MIB works before trying to understand how to poll it via SNMP.
The MIB is made up of objects, which are referred to by Object Identifier (OID) numbers. Those objects can be any counter,
statistic, or configuration knob managed by the device. These OIDs are a series of integers separated by dots and forming a tree. It’s
much more obvious when looking at it in graphic form, such as Figure 2-24.
89
||||||||||||||||||||
||||||||||||||||||||
The Root flows as iso (1), org (3), dod (3), and Internet (1). The Internet (1) is classified as directory (1), management (2),
experimental (3), private (4). The directory (1) is subclassified as mib-2 (1) that are further subclassified as system (1),
interfaces (2), and ip (4). The private (4) is subclassified as enterprise (1) that is further subclassified as cisco (9), microsoft
(311), and juniperMIB (2636).
The MIB OIDs are standardized, which means that common objects like interfaces, IP addresses, and system uptime will be using
the same OIDs regardless of the device. Fortunately, there is room for proprietary sub-MIBs to take care of all the platform-specific
objects. Anything related to a Cisco-specific feature will be starting with .1.3.6.1.4.1.9, which translates to
.iso.org.dod.internet.private.enterprise.cisco. The WLC, which is based on AireOS (which is a Cisco acquisition), has MIB OIDs
starting with .1.3.6.1.4.1.14179 for all its Airespace-specific objects (which is the majority of the MIB). For example, the Load
utilization in the receive direction of an access point is object .1.3.6.1.4.1.14179.2.2.13.1.1
(iso.org.dod.internet.private.enterprises.airespace.bsnWireless.bsnAP.bsnAPIfLoadParametersTable.BsnAPifloadRxUtilization). Of
course, it is not possible to remember all this by heart. The names—in parentheses here—are there to help you make sense of the
hierarchy, but devices use only the numbers when communicating. There are many tools online that will allow you to browse a MIB
and find out the specific item you want to configure/monitor via SNMP. Most applications like Prime Infrastructure will not require
you to know any SNMP OID; they will allow you to configure features in their GUI and will use the appropriate SNMP OID in the
background to configure it on the remote device without you having to care about the details.
SNMPv2 allows Get and Set operations. The management station, the SNMP Server, can send an SNMP Get to a certain device
accompanied with a SNMP OID (the long digit sequence .1.3.6.1.xxx) to request the remote managed device to send the value
contained in that OID in its MIB (whether it’s a configuration item or some counter or statistic). The Set operation will allow the
SNMP server to set a specific value in the remote device SNMP MIB, but this works only with configuration items (counters and
other statistic objects can’t be set). Because OIDs have a structure and are sequential numbers (but are not necessarily contiguous),
there is also a getNext method that will return the next value after the previously requested OID. This is useful when you want to
get a list of all interfaces without knowing how many there are in advance, for example, or basically anytime you want to poll a
specific sublist of the MIB without knowing each sub-OIDs in advance by heart. SNMPv2 also brings a GetBulk function (not
existing in v1) that allows you to request a larger amount of OIDs in one go without having to send a “Getnext” for each item
(which would be very costly if you wanted to get a lot of data). All this happens over UDP port 161.
SNMP also has a real-time notification system. You sometimes don’t want to wait for the management station to poll a remote
device to figure out that something went wrong. The managed device itself can decide (based on configurable triggers typically) to
send notifications to the SNMP server dynamically. These are called SNMP traps and use UDP port 162. The notification type sent
in the trap also uses an OID number.
From a security standpoint, it’s better to say that there is none. SNMPv2 uses a “community name,” which some would relate to as
a preshared key, but this couldn’t be more wrong. Each SNMP request needs to specify the community name, which is a string, for
90
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the CISCO web page, the Management tab is selected. The General options of SNMP are selected within the Summary
option. In the content pane, the SNMP system summary displays the details of Name, Location, Contact, System
Description, System Object ID, SNMP Port Number, Trap Port Number, SNMP v1 Mode, SNMP v2c Mode, and SNMP v3
Mode.
The SNMP V3 Users page (shown in Figure 2-26) allows you to configure SNMPv3 users along with their authentication protocol
and encryption protocol (you need to remember what you set there because it will be required to configure the same protocols on
the SNMP server for that user profile). Be aware that there is a default user (called “default”), which you should be removing in
accordance with security best practices.
91
||||||||||||||||||||
||||||||||||||||||||
In the CISCO web page, the Management tab is selected. The SNMP V3 Users option of SNMP is selected within the
Summary option. In the content pane, the SNMP V3 Users displays the details of User Name, Access Level, Authentication
Protocol, and Privacy Protocol.
A Community page, shown in Figure 2-27, enables you to configure SNMPv2 communities, set them as read-only or read-write,
and enable or disable them. Be aware here as well that there is a default read-only community called “public,” and a default read-
write community called “private.” Any read-write community name will be replaced with asterisks in the GUI, but the name will
show if you click it. One more security measure (that doesn’t make it really bulletproof compared to v3) in v2 is that you can
configure an IP and subnet mask associated to a community. This restricts the IP address(es) that can source requests to the WLC
using this community. You typically will use a /32 mask and specify the SNMP server IP address, but it is also possible to specify
an IP range using a different mask.
In the CISCO web page, the Management tab is selected. The Communities of SNMP is selected within the Summary
option. In the content pane, the SNMP v1/v2 Community displays the IP Address (Ipv4/Ipv6) of public and other two
communities. The IPSec checkbox is shown under IPSec Parameters.
Below these pages, you can see all SNMP traps that were sent since the last reboot (the Trap Logs page) of the WLC. You can see
and modify the list of devices toward which the WLC will send SNMP traps (the Trap Receivers page), and you can select which
traps will be sent in which situation in the Trap Controls page, as shown in Figure 2-28. This trap control page has many traps
enabled by default, but you may want to enable more to optimize some Prime Infrastructure features. Be aware that there may be
additional traps you can enable from the WLC command line compared to what is available in the GUI, depending on the WLC
version you are using.
92
Technet24
||||||||||||||||||||
||||||||||||||||||||
At the top of CISCO WLC webpage, the Management option is selected. On the left pane, the Trap controls are selected
within the SNMP options under the Summary of Management. The right pane displays the SNMP trap controls with the
Client tab selected. Under the Client tab, the Exclusion, MaxClients Limited Reached of Threshold set to 90, and Nac Alert
checkboxes are selected.
Many great tools exist to test SNMP from your laptop to understand better how it works (many UNIX-based platforms even have it
in the terminal by default, but Windows requires libraries to be installed). A great concept is the snmpwalk, which basically will do
SNMP GETs on the whole MIB of the device, allowing you to see all the OIDs in the device and their hierarchy. It’s also great for
verifying SNMP connectivity without having to remember a specific OID. For example, the command snmpwalk -v 2c -c public
10.10.20.30 will run a walk on the MIB of device 10.10.20.30 with the community “public” on version 2. Most tools will translate
the long integer-based OIDs to their textual meaning (or at least parts of the OID). Example 2-8 provides a short example (the total
output was thousands of lines).
Example 2-8 Example Output of an SNMP Walk
DHCPv4
93
||||||||||||||||||||
||||||||||||||||||||
Any DHCP server receiving this can reply with a DHCP OFFER targeted to the client MAC address on UDP port 68, as
illustrated in Figure 2-30. This offer is accompanied with the DHCP server IP address as well as basic options like subnet mask
and default router, but also a SYSLOG server IP address, a DNS server IP address, a TFTP server IP address, or a Cisco WLC
IP address, to just give a few examples.
The client, which may have received several offers, will choose one and will send a DHCP REQUEST toward the specific
DHCP server IP address, specifying again the IP address that was offered, as shown in Figure 2-31.
The server will reply with a final DHCP ACK (or NACK in case it does not agree) to validate the address assignment, as shown
94
Technet24
||||||||||||||||||||
||||||||||||||||||||
There are a few particularities worth mentioning. The IP address is leased for a certain time (which is mentioned as a field in the
DHCP exchange) decided by the server. The client will typically try to extend its IP lease (usually when it reaches half of the lease
time) by sending a DHCP REQUEST for the same IP address again. The server can then choose to extend it or not.
Clients, when connecting to a network (wired or wireless), might have the “reflex” to start by sending a DHCP REQUEST (instead
of the DISCOVER broadcast you would expect) and requesting the IP address they previously had in their last connection. If still
available, the DHCP server may very well grant the client to reuse that address.
So far, it would seem that the DHCP server must be present in the same subnet as the client because broadcasts are used, and this is
correct. However, it does not seem practical to have one DHCP server in each VLAN and subnet for the whole network because it
defeats the centralization purpose of DHCP. The way around this is to configure proxies—that is, devices that will take the DHCP
broadcast sent by the client and unicast it toward the DHCP server and also forward the DHCP reply back to the client. Both the
WLC and network switches (having an SVI in the subnet) can do this task. The DHCP server knows for which subnet the request is
by looking at the DHCP relay IP address, which will be the WLC dynamic interface in the subnet or the switch SVI in the same
subnet as the client. This becomes very practical because it restricts the need of broadcasts spreading long distances and allows you
to have one centralized DHCP server, present on a single VLAN but handing out IP addresses in many different subnets. The
DHCP server can have reservations (based on MAC addresses or hostnames, specific clients will always receive a reserved IP
address for themselves) or also exclusions (a specific subset of IP addresses in the subnet range are not handed out to clients
because they are used for some servers with static IP mappings).
Focusing on wireless clients behind a Cisco WLC, there are two modes of operation from a DHCP standpoint. In the first one, the
WLC has DHCP proxy disabled for that client interface and will then let the client DHCP broadcast through in the hope that there
is either a DHCP server present on that subnet or a switch SVI is configured to relay the request to a DHCP server. The second one
is when DHCP proxy is enabled, the WLC dynamic interface will then proxy the request to the configured DHCP server(s). Each
dynamic interface can be configured with two DHCP server IP addresses, which will both be used to forward DHCP DISCOVER
messages. The WLC also hides the real DHCP server IP address to the client and pretends that the DHCP server is whatever IP
address is configured on the virtual interface of the WLC. This allows the client to believe that a single DHCP server is present in
the whole network, no matter toward which other WLC it roams to (provided that they use the same virtual interface IP address),
while in reality it may be a different DHCP server replying to the client.
For access points to learn the IP address of the WLC, the network administrator can configure DHCP option 43. Option 43 is a
hexadecimal string that contains the IP address of one or more WLCs that the AP can try to join. In the case of one WLC, the
format will be F104.<ip in hex>, while in the case of two WLCs it will be F108.<ip in hex of first WLC><ip in hex of second
WLC>, and for three WLCs it will be F10C followed by the hex IP addresses. So, you can understand from these examples that
the prefix must be F1 followed by the amount of WLC IP addresses that follow multiplied by 4 (technically it represents the length
of the field in bytes, and since an IP address will take 4 bytes…). For example, providing the IP address 192.168.1.10 in option 43
will be f104.c0a8.010a. Providing IP addresses 192.168.1.10, 192.168.17.10, and 10.10.20.40 will be
f10c.c0a8.010a.c0a8.110a.0a0a.1428.
Many documents online combine the option 43 (WLC IP address) with the option 60 (vendor class) despite the two options not
being directly linked. Option 60 is sent by the access points in the DHCP discover where they specify their model in a text string. It
is possible for the DHCP server to restrict certain pools or return the option 43 only for specific client types. Translated for Cisco
APs, this means that you could have a DHCP pool that returns only option 43 when the AP requesting an IP is of a particular
model. This does not really scale well if you have APs of various models. Option 60 is not mandatory at all to have option 43
working fine. Example 2-9 provides a simple example of a DHCP pool configuration in IOS to return option 43 for access points.
95
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
DHCPv6
IPv6 can very well function without DHCP because hosts can figure out their neighbor routers and assign themselves an IPv6
address. However, there is still the whole “configuration” and “DHCP options” side of things: the network administrator might still
want to assign specific server and subnet configuration to the hosts. Example 2-10 provides a small example of a DHCPv6 pool on
IOS.
Example 2-10 Example of a DHCPv6 IP Pool Configuration on IOS
97
||||||||||||||||||||
||||||||||||||||||||
In the top section of the window, the column header reads: No, Time, source, destination, protocol, and Info. In the bottom
section, the line "Frame 1: 112 bytes on wire (896 bits), 112 bytes captured (896 bits) on interface 0. The "Request Option
code and Identify Association for Non-temporary Address" are highlighted.
If the DHCP server is configured with those options, it will return an Advertise packet (as shown in Figure 2-34) with up to three
WLC IPv6 addresses in order of preference.
98
Technet24
||||||||||||||||||||
||||||||||||||||||||
The DHCP v6 advertise packet shows the table data at the top with the headers time, source, destination, protocol, and
info; the second row for advertise is selected. Followed by the CAPWAP access controller (highlighted) shows the value
for option, length, value, and two CAPWAP access controller address.
These packets will be followed by Request and Reply packets, similar to the DHCPv4 REQUEST and ACK to confirm the
transaction.
To configure option 52 on a Windows Server 2008/2012, go to the DHCP manager and expand the DHCP tree. Right-click the
IPv6 section and choose Set Predefined Options (because the option 52 does not exist by default, we need to add it). This is
illustrated in Figure 2-35.
99
||||||||||||||||||||
||||||||||||||||||||
In the DHCP window, "Set Predefined Options" under IPv6 is selected in the navigation pane. The content displays the
column headers "Option name, vendor, value, and class." In the left pane, "Scope options" is selected under Actions.
The Predefined Options and Values for v6 window will pop up. Choose DHCP Standard Options in the option class drop-down and
click Add. The result is illustrated in Figure 2-36.
In the "Predefined Options and Values for v6" dialog box, the DHCP Standard Options is selected within Option class
drop-down, the option name is selected from a drop-down box with three buttons, Add, Edit, and Delete. The option class
and option name drop-down boxes are highlighted. The Description text box is shown below. The Value console box with
Edit Array button is shown. The OK (selected) and Cancel buttons are shown at the bottom.
100
Technet24
||||||||||||||||||||
||||||||||||||||||||
Now expand the scope that you want to use for your APs IPv6 assignment. Right-click Scope Options, and then select Configure
Options. This is shown in Figure 2-38.
Figure 2-38 Configuring Options for the Specific Scope for APs
In the DHCP window, the Scope Options folder within IPv6 in the DHCP is selected. In the content pane, the two rows of
Options Name, Vendor, Value, and Class are listed. Below that, the Configure Options in a dialog box is selected. The
Scope Options in the Actions pane is selected.
You can now choose the option 52 in the list of available options, and you can see it wears the name you gave it. In the New IPv6
Address field, enter the management IP of the primary WLC and click Add. You can then also add secondary and tertiary if you
like. This is illustrated in Figure 2-39.
101
||||||||||||||||||||
||||||||||||||||||||
Figure 2-39 Configuring Options for the Specific Scope for APs
In the Scope Options dialog box, the General tab is selected that displays the Available Options and its Description is a
console box with one of the options is highlighted. In the Data entry section, the New IPv6 address box with Add button is
highlighted. The Current IPv6 Address text box with three buttons are shown beside. The OK (selected), Cancel, and
Apply buttons are shown at the bottom.
You can then verify this assignment on the AP itself (see Example 2-11; the output has been trimmed to show only the relevant
lines for your understanding).
Example 2-11 Verification of the DHCPv6 Status of the AP
Click here to view code image
MyAP# show ipv6 dhcp interface
DNS
Domain Name System (DNS) is a name resolution method used to translate Internet domain names to IP addresses (but not
necessarily only in that direction). DNS works on a hierarchy of domain levels. If we use the very famous Internet domains as an
example, you have one (technically more, but still a very limited amount) root name server for the .com domain. That root server
102
Technet24
||||||||||||||||||||
||||||||||||||||||||
Software.cisco.com
Name: origin-software.cisco.com
Addresses: 2a02:a000:1:386:ac5
23.218.189.151
Aliases : software.cisco.com
We can already picture how flexible this system is, because it allows you to return different IP addresses (v4 or v6) as well as name
aliases. The whole domain name structure is also very scalable, because you could have server-
name.department.continent.company.extension and can offload the administration of all the servers of that small team to the local
continent-specific department of your company. Other parts of the company could manage their own DNS server responsible for
their own subdomains without having to argue with you. It is important to note that what a DNS server returns to you will not
necessarily be the same as what it will return to another requestor. A DNS server can very well give different replies to load-
balance the load to several IP addresses or simply hand out a different IP mapping, depending where you are located on the globe.
There is also the concept of reverse DNS lookup, where you look up an IP address and the DNS server will let you know what
name is linked to it, which can be practical in many situations.
There are several types of DNS records:
A (for Address) record: These are the “main” records and contain a host IPv4 address.
SYSLOG
Syslog is a message logging system that started on UNIX but spread to most networking products because it is independent of the
client and server types in use. The whole concept is about the syslog device sending messages (that don’t need any form of
acknowledgement) to a server that will record all of them. Server software differs in the way they allow the administrator to browse
103
||||||||||||||||||||
||||||||||||||||||||
3. Error: This is the default logging level of many devices. It will log anything that is not a normal behavior.
4. Warning: Displays warning conditions that may not cause problems but shows possibly unexpected behavior.
Command Purpose
WLC> config logging syslog Configures the IP address of the syslog server where WLC will send its log messages
host <ip>
Will display all the buffered message logs sent and logged by the WLC (unless you choose a
WLC> show msglog
different severity for syslog level and for “buffered log level”)
WLC> config ap syslog host Configures the syslog server for APs to directly syslog their messages to it
global/<apname> <ip>
WLC> config ap logging level Configures the AP syslog logging level
<level>
WLC> config ap logging facility
<name> Configures the AP syslog facility
104
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figure 2-40 Kiwi Syslog Server Output When Receiving Syslog Messages
NTP
Despite being more and more critical, Network Time Protocol (NTP) is still not heavily used by network administrators. NTP allows
network devices to periodically resynchronize with a trusted time source and opens the doors to the amazing feeling of having the
logs of all your network devices synchronized to the millisecond, allowing you to cross-check what happened during a particular
event in the logs of multiple devices.
A very common NTP version is NTPv3 (and is the one used in the lab), but newer WLC software supports NTPv4. They are,
however, all compatible with each other. The configuration is pretty straightforward on the WLC, in the web interface Controller
page under the NTP > Server menu. You can add several NTP servers there, as well as configure the NTP polling interval. After
your network device got the right time, it’s very unlikely that it needs to keep polling it frequently, so very long NTP polling
intervals are fine. However, because network devices don’t use atomic ultra-high-precision clocks, it might start to slide a few
seconds after weeks or months of uptime. Therefore, an NTP polling interval of a few hours is fine and ensures your device’s time
is always as accurate as possible.
NTP also provides some form of authentication security with configurable keys.
While the inner workings of NTP are a bit beyond the scope of the CCIE exam, it is interesting to note that the NTP server will give
the time in UTC format (without any time zone skew). It is thus acceptable to have an NTP server in another time zone. What about
network latency then? Well, the NTP protocol also measures the network delay and adjusts the time received from the NTP server
with the estimated delay it took the packet to arrive to the device, making sure the latency does not affect the time synchronization
to a relevant extent. All that is pretty neat, but how do you set up an NTP server and how does a device decide which NTP is most
reliable?
NTP uses the concept of stratum. A stratum-0 server is a reference clock and is not available on the network, but it will be
connected to an NTP server that will be defined as a stratum-1 server (because it is one hop away from the reference clock). Any
server that uses this stratum-1 server will be defined as a stratum-2 server, and so on. NTP only tolerates up to 16 stratum levels. If
you set up one of your device as NTP server, its stratum will be S+1, S being the stratum of the reference NTP server used by your
NTP server to get its time. If you decide to not have a reference server and set the time manually on your device, the stratum will
be automatically set as 16. This is how NTP clients will know which server is the most reliable.
Configuring a router as NTP server is quite quick:
Click here to view code image
Router# config term
Router(config)# ntp master 4
Router(config)# ntp source Vlan1
105
||||||||||||||||||||
||||||||||||||||||||
Command Purpose
Shows the current time and time zone as well as NTP settings and sync
WLC> show time
status
Configures a given IP address as NTP server (of index 1 to 3 if you want to
WLC> config time ntp server <index> <ip>
have several sources)
WLC> config time ntp interval <seconds> Configures the interval at which the WLC will resync its clock
WLC> config time ntp key-auth add <key index> Configures the NTP key (optional)
md5 ascii <key>
WLC> config time ntp auth enable <server index> Configures authentication on NTP server index X by using the keys of key
<key index> index Y
Summary
This wraps up the infrastructure chapter of this book. As you can see, a CCIE Wireless does not need to know all the tiny details of
those protocols. You can, however, expect that some of these protocols will appear as configuration tasks in the CCIE Wireless lab
exam or will be required to bring the connectivity up. To declare yourself ready for the exam, all the knowledge of this chapter
must be natural and common knowledge to you as you make sure the infrastructure network is ready before you configure anything
wireless related. You can also expect this chapter to be a good source for troubleshooting actions, when you receive the
preconfigured topology in the exam and some items were intentionally misconfigured (or simply missing sometimes) for you to
troubleshoot. There is no point in trying to configure advanced wireless features (multicast or FlexConnect setups) if your
infrastructure has dodgy VLAN configuration or suspicious multicast forwarding. Be sure to master this chapter before moving on
to the next ones!
106
Technet24
||||||||||||||||||||
||||||||||||||||||||
107
||||||||||||||||||||
||||||||||||||||||||
108
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figure 3-1 shows the roles for point-to-point and point-to-multipoint bridging:
109
||||||||||||||||||||
||||||||||||||||||||
110
Technet24
||||||||||||||||||||
||||||||||||||||||||
111
||||||||||||||||||||
||||||||||||||||||||
112
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
114
Technet24
||||||||||||||||||||
||||||||||||||||||||
The following are highlighted on the output frame: 802.11 radio information, 802.1Q virtual LAN, PRI:0, DEI:
0, ID: 3, 0000 0000 0011 ID: 3, Cisco wireless LAN context control protocol, station MAC, and association
VLAN ID: 3.
When configuring the bridge role at the interface level, you can use the command station-role root bridge to limit the
connections to non-root bridges and WGBs only. If you need to allow regular clients to connect on that root bridge you
can configure the role as station-role root bridge wireless-clients. Adding the “wireless-clients” keyword configures
the root bridge to perform wireless bridge links with Cisco infrastructure clients as explained before, but at the same
time also allows regular wireless clients to associate as if the root bridge were a normal 802.11 access point. The same
logic is possible with the non-root bridge role. Use the command station-role non-root wireless-clients to configure
the non-root bridge as an infrastructure client that will associate with a root bridge and establish the bridge link, but also
as an access point to allow associations from regular wireless clients. Just be aware that, in these cases, the same radio is
sharing the medium/air-time (and transmit opportunity, performing contention, scanning, etc.) between the two roles, so
we can say it is literally sometimes bridging to the other side and sometimes acting as AP for clients.
Workgroup Bridge
Widely used in different designs, the WGB is a versatile wireless client that associates to a root bridge or an AP (Cisco
autonomous or lightweight, or even third-party AP) to pass traffic for one or multiple devices connected to its Ethernet
interface (connecting those remote devices back to the infrastructure where it wirelessly associates). This is a powerful
wireless client that could be static or mobile, using internal antennas or external antennas that better fit the requirements
(such as when directional antennas are used to point directly to the root and better align/focus the RF signal for long
distances).
Because this WGB role is not defined by the 802.11 standard, its Wi-Fi implementation is proprietary, and this is why
you normally can’t connect a WGB (or similar type of device) from a given brand to a root wireless device of a
different brand; in the end, the WGB is not really an 802.11 STA normal client. The WGB is truly a proprietary
infrastructure client (where its infrastructure behavior is defined by the vendor, in this case, Cisco).
Cisco also developed for its IOS Autonomous WGBs the Universal mode (radio role: station-role workgroup-bridge
universal), where the WGB basically acts as a regular 802.11 wireless client (normal client) using the MAC address of
the device directly connected to its Ethernet interface as the Wi-Fi and only MAC address that the root AP will see.
This limits the capabilities of a WGB but allows normal associations with any 802.11 access point (from any vendor),
115
||||||||||||||||||||
||||||||||||||||||||
116
Technet24
||||||||||||||||||||
||||||||||||||||||||
Bridge Group 1:
Address Action Interface Age RX count TX count
34db.fd22.f1d0 forward Vi0.2 0 0 0
f09e.6342.32f7 forward Vi0.2 0 1 0
Bridge Group 3:
101f.7469.fffd forward Gi0.3 0 1618 1065
f09e.6342.32e7 forward Vi0.3 0 1066 1292
As you can see, these IOS autonomous WLAN devices have their bridge table populated with all the MAC addresses
that they have learned (like a switch MAC-address table), segregated by bridge-groups, based on the VLAN where the
device is located, along with the interface each MAC address was learned from. You can see if the address was learned
over the GigabitEthernet interface (like the entry highlighted in Example 3-6, which is for a wired client behind the
WGB, heard and classified through the subinterface known as Gi0.3) or over a radio interface via the wireless link (such
as all the other MAC addresses in the output, which are learned by this WGB in the example via the wireless/radio
interfaces identified as Vi—for Virtual, classified based on their VLAN/subinterface/bridge-group. These are MAC
addresses coming from the root side; they can be other wired devices behind the root or wireless clients associated to
the root). As can be concluded, two MAC addresses were learned over the native VLAN (Bridge Group 1) and two
other MAC addresses were learned over the VLAN/subinterfaces created for Bridge Group 3.
Something important to consider with WGBs and the bridge table they create is the behavior of the wired devices
behind the WGB; specifically, the so-called passive client behavior. If a wired client behind the WGB doesn’t transmit
traffic for an extended period of time, the WGB will remove the device from its bridge table (or if the wired client never
starts some traffic when coming up for the first time or after getting deleted, the WGB will never populate its bridge
117
||||||||||||||||||||
||||||||||||||||||||
Add static/manual MAC address entries to the bridge table: By doing this, the devices’ MAC addresses
configured manually will always be present in the bridge table, without aging (so will not get deleted). Just use the
global configuration mode command bridge <1-255> address H.H.H forward gigabitEthernet 0.
Mobile WGB
Used in a mobile deployment—for example, in transportation (such as connecting trains to Wi-Fi in subways) or health
care (medical equipment carts that use the WGB as their Wi-Fi NIC to be always connected anywhere there is WLAN
coverage), the WGB needs to meet requirements that are normally expected from a regular mobile client; that is, make
appropriate decisions about when and where to roam, perform Fast-Secure roaming if EAP authentication is used,
implement smart scanning, and others. The Cisco IOS autonomous WGBs let you set up some settings that help with
such mobile requirements.
For Fast-Secure roaming (methods used to perform fast roaming when secure Wi-Fi authentication is used, by avoiding
the reauthentication when moving between APs using caching techniques), as of this writing in early 2018, Cisco WGBs
only support CCKM as a Fast-Secure roaming method, which means that the infrastructure WLAN/SSID where the
WGB connects should also be configured to allow CCKM for this Fast-Secure roaming to occur. All you need in the
WGB setup is the following SSID configuration command option for the key management method, and the rest of the
SSID configuration is the same as for WPA/WPA2 enterprise (more about security later in this chapter): authentication
key-management cckm.
By default, when looking for the best root (for initial association or to roam), the WGB scans all country channels
supported in its regulatory domain, so you can imagine that it takes some time for the WGB to finish scanning all
channels (a lot more channels exist in the 5 GHz band than in 2.4 GHz, and if there’s a DFS channel, scanning takes
even longer because it must be done via passive scanning—waiting to hear beacons instead of actively probing). So to
accelerate roaming, it is recommended to configure the WGB to scan only the channels that are used by the WLAN
infrastructure; for example, if you’re using the 2.4 GHz band and the infrastructure root APs are configured only for
channels 1, 6, and 11 (as they should), then configure the WGB radio interface command mobile station scan 1 6 11 to
scan only those three channels.
But when is the WGB going to start the roaming? Because no specific 802.11 rules force/trigger a Wi-Fi roaming, each
client vendor relies on multiple factors to trigger a roaming decision, such as current root beacon loss, current signal
quality going down (and if available, other roots around heard with better signal quality), shifting down to low data rate,
packet retries and loss, and others. WGBs work with most of the typical triggers for a roaming event, but the following
three can be manipulated:
Packet retries: By default, if the WGB (or non-root bridge) reaches the maximum packet retries because it never
received an ACK for a data frame that is trying to transmit to the root parent, it will start roaming and disassociate
from the current root. One single packet that was never confirmed to be received by the root will trigger this event,
so you can not only manipulate the amount of retries required to take this decision but can tell the WGB to better
118
Technet24
||||||||||||||||||||
||||||||||||||||||||
In some deployments, the WGB could be moving (and hence roaming) at high speeds, much faster than regular mobile
clients; for example, when the WGB is installed in high-speed rail coaches to provide them with connectivity. As the
train moves, the WGB in the coach roams from one root AP to the next one installed along the railway track.
In such scenarios, train speed could be about 100 km/h, with the root APs placed about 200–300 meters apart along the
track. The only way for the WGB to support roaming between those APs while moving at such high speeds is by
configuring some required settings for high-speed roaming in the entire WLAN deployment.
First, as of this writing in early 2018, this is supported only by Cisco Aironet 3600 and 3700 series APs acting as WGBs,
and they must associate to a WLAN infrastructure that supports 802.11v BSS Transition. So if the root APs along the
railway track are lightweight APs managed by a WLC, the WLAN/SSID at the controller must have 802.11v BSS
Transition enabled. This allows for the WGB to receive (and request) neighbor list information, which is provided by the
current root AP, and helps the WGB to identify possible next root APs to roam to (and their channels). Knowing their
channels helps the WGB perform a more efficient and faster scan when roaming.
119
||||||||||||||||||||
||||||||||||||||||||
The Cisco IOS autonomous WLAN devices support all the Layer 2 security methods defined by the 802.11 standard as
of the writing of this book, from open system authentication (without encryption and with static WEP or even dynamic
WEP using 802.1X/EAP) to shared key authentication, as well as all flavors of WPA (versions 1 and 2) as summarized
in Table 3-1.
Table 3-1 WPA/WPA2 Layer 2 Security Frameworks
Technet24
||||||||||||||||||||
||||||||||||||||||||
You can even do MAC address authentication (against a local list or against a RADIUS server), which is not really a
security authentication method defined by the standard (there’s nothing to configure on the client side, just validation of
its MAC address at the root side), and even combine MAC address authentication and/or EAP authentication. We do
not cover all those security methods in this chapter but will share some important guidelines for deploying WPA/WPA2
methods in Cisco IOS autonomous APs and bridges/WGBs.
Remember that when doing WPA/WPA2 Enterprise with an 802.1X/EAP authentication method, the specifics of the
actual EAP method to be deployed are implemented/configured at the authentication server and the client supplicant,
not at the authenticator, which is the role of a root AP or root bridge when authenticating wireless clients. Therefore,
the basic configuration in IOS autonomous WLAN devices is as general and simple as described in Table 3-1; you don’t
need to specify the EAP method to be used or add credentials or certificates or any other details. The base setup is
divided into two sections:
SSID configuration: At the SSID configuration level, you define the authentication method (open system
authentication + EAP or PSK) and the key management method (whether it is the certified WPA/WPA2 key
management or the Cisco version for Fast-Secure roaming known as CCKM, which is used a lot for WGB mobile
deployments as explained earlier).
Radio encryption: At the radio interface configuration level, you define the encryption cipher (TKIP or AES-
CCMP) to be used for the SSID (or for the SSIDs if configuring a root with multiple SSIDs for different VLANs, in
which case the encryption is specified per VLAN).
So if you want to configure WPA2 Personal, Example 3-7 gives you the security commands required for the
configuration of the SSID settings.
Example 3-7 WPA2 Personal SSID Configuration
Click here to view code image
Bridge(config)# dot11 ssid WPA2-PSK
Bridge(config-ssid)# authentication open
Bridge(config-ssid)# authentication key-management wpa version 2
Bridge(config-ssid)# wpa-psk ascii <YOUR-PSK>
But if you want to configure WPA2 Enterprise, the configuration is similar to Example 3-8.
Example 3-8 WPA2 Enterprise SSID Configuration
Click here to view code image
Bridge(config)# dot11 ssid WPA2-EAP
Bridge(config-ssid)# authentication open eap eap_methods
Bridge(config-ssid)# authentication network-eap eap_methods
Bridge(config-ssid)# authentication key-management wpa version 2
If CCKM will be used for Fast-Secure roaming, the only change needed is on the key-management command, using the
following instead: authentication key-management cckm.
Note
121
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
When the SSID is configured to authenticate the clients with 802.1X/EAP, doing some type of EAP authentication
method, the client side (non-root bridge or WGB in our examples) is acting as the 802.1X/EAP supplicant.
Consequently, the client needs to be configured with the specific EAP method settings required to be 802.1X/EAP
authenticated by the RADIUS server based on the EAP method selected (each EAP method has its own requirements
and options) and valid credentials.
The Cisco IOS autonomous WLAN devices acting as 802.1X/EAP supplicant clients support most of the commonly
used EAP methods in wireless, such as EAP-TLS, EAP-FAST/MSCHAPv2, and PEAP-MSCHAPv2. We do not cover
in this book all the different setups for each EAP method supported; several documents and configuration examples are
already available at Cisco.com and share the steps on how to configure each method when these devices are acting as
clients, such as the following:
How to Use aIOS WGB with EAP-TLS Authentication in a Cisco Unified Wireless Network:
https://www.cisco.com/c/en/us/support/docs/wireless/4400-series-wireless-lan-controllers/100864-wgb-eap-tls-
cuwn.html
Workgroup Bridges with PEAP Authentication Configuration Example:
https://www.cisco.com/c/en/us/support/docs/wireless/virtual-wireless-controller/115736-wgb-peap-00.html
We suggest that you check such documents and practice in your own lab as many methods as you can, especially the
ones that involve certificate management, such as EAP-TLS with client and root CA certificate or PEAP with root CA
certificate, because it would be good for you to get familiar with certificate management in these devices. This is
handled with very typical IOS certificate management/crypto PKI commands, so you can also find some good
documents related to this topic on other Cisco IOS products and technologies. Obviously, even if a configuration
example is using an old RADIUS server like ACS, you look for documentation on how to deploy the specific server
settings in your applicable RADIUS server, like ISE nowadays; remember that the configuration in the 802.1X/EAP
supplicant side is basically the same for each EAP method regardless of the RADIUS server used.
In this section, we use EAP-FAST/MSCHAPv2 as the EAP method for example purposes, which is highly
recommended because it is very secure, doesn’t involve certificate setup (so it is simple to deploy), and is supported by
the local RADIUS server that is covered in the next section. It is normally used in isolated autonomous deployments,
124
Technet24
||||||||||||||||||||
||||||||||||||||||||
125
||||||||||||||||||||
||||||||||||||||||||
When doing 802.1X/EAP authentication, you need a RADIUS server. The authenticator (in our case the root AP or root
bridge) should be configured to communicate with a RADIUS server to authenticate the clients with the specific EAP
method to be used. This is achieved with the configuration explained previously, which covered an example of how to
point the authenticator to RADIUS server(s), which could also be external servers (such as Cisco ISE).
The Cisco IOS autonomous root APs/bridges support a local RADIUS server feature, which let you enable the RADIUS
service in the AP/bridge itself, so the device can also play the role of the authentication server (which is already acting
as authenticator) and even for other authenticators (for other root APs/bridges using this device as their external
RADIUS server). This is helpful for deployments where you don’t have external RADIUS servers available but you still
want to configure a secure EAP method for the authentication. In this case, when you define the RADIUS server at the
global configuration level of the root acting as authenticator (as explained in a previous section with Example 3-11),
you configure it with the IP address of the AP/bridge that will have this local RADIUS server feature enabled (its BVI1
interface IP address). This obviously means that the root AP/bridge playing this RADIUS/authentication server role will
point to itself. (The RADIUS server still needs to be added globally but is configured with its own IP address.)
The local RADIUS server supports three authentication methods: MAC authentication and two Cisco developed EAP
authentication methods, LEAP and EAP-FAST. All three authentication methods are enabled/allowed by default when
the local RADIUS server feature is enabled, so as a good security practice, it is recommended to disable the methods
that won’t be used. For example, if the most secure and recommended method of the three is to be used (EAP-FAST),
then MAC and LEAP should be disabled, as in Example 3-15.
Example 3-15 Disable Authentication Methods in Local Server
Click here to view code image
Root(config)# radius-server local
Root(config-radsrv)# no authentication leap
Root(config-radsrv)# no authentication mac
Within that radius-server local configuration mode/section, you can also set up and modify other RADIUS server
settings, such as the following:
Add the AAA clients (NAS): The AAA client or Network Access Server (NAS) is basically the authenticator(s)
that will be using this RADIUS server to authenticate clients. So if you have a point-to-point bridge link, the root
bridge is acting as the authenticator, but if you configure this root with the local RADIUS server feature, this unit is
also acting as the authentication server. Hence, the NAS is itself, so you will be adding its own IP address as the
NAS within the local RADIUS server section and using a shared secret key that matches the one configured when
the RADIUS server to be used by this NAS/authenticator was globally added using the radius server configuration
settings (configured within the configuration mode Root(config-radius-server), as demonstrated in Example 3-11).
Configure specific EAP-FAST settings: EAP-FAST is a very good and secure EAP method with multiple variants
and options that we do not cover in this book. Still, it is important to mention that you can modify some of its
126
Technet24
||||||||||||||||||||
||||||||||||||||||||
NAS : 192.168.2.11
Successes : 1 Unknown usernames : 0
Client blocks : 0 Invalid passwords : 0
Corrupted packet : 0 Unknown RADIUS message : 0
No username attribute : 0 Missing auth attribute : 0
Shared key mismatch : 0 Invalid state attribute: 0
Unknown EAP message : 0 Unknown EAP auth type : 2
Auto provision success : 1 Auto provision failure : 0
PAC refresh : 0 Invalid PAC received : 0
Filters
127
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Radio Settings
So far, we have covered some features and configuration settings that are handled at the radio interface level, such as
the roles, the encryption, VLANs, applying ACLs, and others, which can be considered radio settings. This next section
is specifically about some of the wireless radio settings that are important to consider not only for the wireless CCIE but
also for live autonomous deployments.
Channels
For bridge links, the channel is defined only at the root, because the clients (non-root and workgroup bridges) are acting
as wireless clients and have to scan the channels available in the regulatory domain of the radio band selected until they
find the channel on which the root operates. This client scan can be passive scanning, listening for beacons, or active
scanning, proactively probing. In any case, the purpose is to find a root (on any supported channel) that is configured
with the same SSID, so the client can select it and start the association process. In the end, just like for regular wireless
associations, the client aligns to the channel used by the root parent selected, and this is the reason why you can’t even
configure channel settings or restrictions at the non-root or workgroup bridge clients level (other than the exception
already explained earlier in this chapter about the mobile station scan command that restricts the WGB to scan only
specific channels for faster roaming decisions).
At the root AP or bridge, you can leave the default channel setting for the root to select the “least-congested” channel,
which is a decision based on some initial scanning that the root performs in all country channels (allowed by the
regulatory domain of the AP/bridge model) to figure out what channel seems to be the best (least busy) when the device
decides to assign a specific channel to its radio interface. However, your root may end up with a non-optimal channel
with this technique. For example, if both channels 1 and 6 are busy, the root may choose channel 3 as the quietest. As
an RF expert, you know that choosing channel 1 and 6 (and sharing with another cell) is better than choosing channel 3
(and being sure to interfere with both channels 1 and 6). Alternatively, you can use the radio interface command
channel to specify a static channel number, or to let the radio interface dynamically select the channel it considers
(perceives) as the best by using the default commands channel least-congested for the 2.4 GHz radio or channel dfs
for the 5 GHz radio.
When configuring the 5 GHz radio of the root APs/bridges, you can not only specify channel width (for example, do 40
MHz channel bonding), but you can also block some specific 5 GHz bands so their channels are not selected by DFS
(dynamic frequency selection). For example, using the radio interface command dfs band 2 block, if the radio is
configured for dynamic channel assignment instead of static channel, the AP will never select (auto-assign) a channel
from the 5 GHz UNII-2 band. This example is a very good idea because remember that the UNII-2 band has some
restrictions and specific rules that can cause the radio to jump from the channels due to DFS events (like radar
detection), causing disruptions and even outages if, for example, your only root bridge connecting some remote
buildings is affected by such events.
Parents
130
Technet24
||||||||||||||||||||
||||||||||||||||||||
Transmitter Power
Regarding the radio transmitter power-level settings, the default is always the maximum supported by the radio, but you
can use the radio interface power local command to specify the power level in case it needs to be decreased due to
design requirements. In addition, you can use the power client radio interface commands at the root, so it can tell the
client (using CCX messaging during the association phase) what transmitter power level to use; it could let the client use
its maximum transmitter power supported, tell it to use a specific power level (in dBm), or even tell the client to use the
same transmitter power as the one used by the root (with the command power client local). This last option, forcing the
clients to use the same power level as the root, is helpful in avoiding asymmetric RF links that could cause, for example,
the root to hear the client with a strong signal strength (because the client is using its maximum transmitter power) while
the client can’t hear the root very well if it is using a lower power. This kind of asymmetry could cause packet drops
and retransmissions, disconnects, and the like.
Antennas
Another important setting to consider is about the antennas, mainly when using external antennas, which is typical in
bridge links. The antennas are passive hardware devices attached to the AP/bridge connectors, but the radio can’t
recognize the antenna type/model or specs, so you need to specify the antenna gain with the radio interface command
antenna gain. The antenna will still propagate RF signals with its actual gain regardless of this command (again,
because it is a “passive” piece of hardware that can’t be configured, so its behavior can’t be modified), but the
importance of this command is that the AP/bridge can properly calculate transmitter power levels and adjust to
regulations depending on the channel used, helping you to avoid breaking the law when using an antenna that you
probably shouldn’t be using, mainly because these bridge links with external antennas are normally used in outdoor
environments, which could be more restricted.
Data Rates
The last key radio interface setting we want to cover is about the speed command, used for the data rates configuration.
Both radio interfaces have defaults allowing all supported data rates on each band, and the recommendation is usually
to disable the lowest data rates. This configuration not only applies to the well-known recommendation about disabling
the 802.11b (DSSS and HR-DSSS) data rates 1 Mbps, 2 Mbps, 5.5 Mbps, and 11 Mbps in the 2.4 GHz radio to avoid the
performance impact of using these rates (due to ERP protection, slow transmissions with 802.11b rates and with clients
connected far away from a good coverage area, and so on). It also helps design your coverage cell or bridge-link “edge”
looking for the minimum data rate that you expect to support for the type of traffic and applications that will be using
the wireless link (regardless of the radio band used). For example, if the requirements of a point-to-point bridge link for
a remote location is to keep a connection of at least 24 Mbps, this data rate will be your lowest rate enabled, and all the
ones below should be disabled; if the wireless link connection is not good enough to stay at or above this data rate, you
should not enable lower data rates. You should improve the wireless link with a better design (different position,
antennas, coverage, and so on) and use the lowest data rate to help you establish your coverage edge (clients out of that
“edge” just won’t associate or will have to drop or roam). The same logic applies to application services behind a WGB.
If their requirements demand keeping the connection above 12 Mbps, for example, you should disable all data rates
below 12 Mbps and leave at least this one as the required data rate.
Mandatory or required data rates are configured in the IOS autonomous WLAN devices using the “basic” word in the
131
||||||||||||||||||||
||||||||||||||||||||
Multicast on Autonomous
As explained previously, multicast traffic is transmitted using the highest mandatory data rate configured in IOS
autonomous devices, but there are a few other important details to consider when dealing with both multicast and
broadcast traffic over the air.
Multicast and broadcast frames are not acknowledged (unlike unicast frames) as per 802.11. Hence, the transmitter of
the frame (say the AP transmitting a multicast frame to a WGB, where the final destination is an application on a client
132
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Summary
Even when the autonomous WLAN devices almost “stopped” their evolution some time ago, they are still widely
deployed in multiple WLAN and IoT environments, mainly in designs where wireless bridges are required, such as the
ones discussed in this chapter.
All the topics and features required for you to understand and successfully deploy and troubleshoot Cisco IOS
autonomous bridges and WGBs were covered, not only for your CCIE journey but also for real-life environments where
an expert is expected to be involved. Make sure you practice all these topics and the many variants around them; check
all the options for every topic from configuration guides, command reference guides, examples or tech notes, from your
lab equipment (testing in one way or another, breaking things and making them work again after some troubleshooting),
and always use the current CCIE blueprint as your reference while you are getting ready for the exam.
136
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figure 4-1 Central Switching (Split MAC) and Local Switching (Local MAC)
The first illustration shows a client transferring data over the air to an AP, followed by the AP transferring
the data over the CAPWAP data tunnel to a WLC. The WLC transfers the data via 802.3 to the cloud. The
second illustration shows a client transferring data over the air to an AP, followed by an AP transferring the
data to a cloud via 802.3. After the cloud, WLC and another cloud are present.
With local MAC, all 802.11 MAC functions are performed at the AP level. Technically, this mode allows the
client’s traffic to be either locally switched at the AP level or tunneled in 802.3 frames to the WLC. The latter is not
supported by Cisco WLCs, and we can compare local MAC to FlexConnect local switching (and local
authentication too, if enabled).
An AP communicates with its WLC through two CAPWAP tunnels: a control tunnel on UDP port 5246 and a data
137
||||||||||||||||||||
||||||||||||||||||||
138
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figure 4-2 Local Mode Configuration Under the AP’s Settings on the WLC GUI
The screenshot shows the Wireless menu selected from the main menu tabs at the top. Access Points section
under Wireless menu is expanded to reveal: All APs, Radios, and Global configuration. Radios is expanded to
list: 802.11a/n/ac, 802.11b/g/n, and Dual-Band Radios. FlexConnect Groups section lists: FlexConnect ACLs,
FlexConnect VLAN, and Templates. A page titled Details for AP-3702I.fcc4 shows six tabs from which
General is selected. The general tab shows three sections: General, Versions, and IP Config. The general section
lists the following: AP Name field box reading AP-3702I.fcc4, Location field box, AP MAC Address, Base
Radio MAC, Admin Status spin box set to Enable, AP Mode spin box set to local, AP Sub Mode spin box set to
None, Operational Status, Port Number, Venue Group spin box (Unspecified), and Venue Type spin box
(Unspecified). Three buttons, Add New Venue, Venue, and Language Name are shown. Under versions section,
the following information is listed: Primary Software Version, Backup Software Version, Predownload Status,
Predownloaded Version, Predownload Next Retry Time, Predownload Retry Count, Boot Version, IOS
Version, and Mini IOS Version. Under IP Config, CAPWAP Preferred Mode, DHCP Ipv4 Address, and Static
IP (Ipv4/Ipv6) checkbox are listed.
FlexConnect is the deployment mode that allows mixing and matching options for switching traffic centrally or locally.
The FlexConnect name was introduced as of AireOS 7.2 to replace the former Hybrid Remote Edge Access Point (H-
REAP). We describe FlexConnect architectures and options more in detail in a later section of this chapter, but a brief
introduction is still needed to clarify some terms and concepts used in the following paragraphs.
We use the expression local switching when a wireless client’s traffic is switched locally on a VLAN of the switch port
where the AP is connected, instead of centrally switched through the WLC.
The AP itself obtains its IP address from either the access VLAN of a port in access mode or the native VLAN of a
trunk port. Wireless clients can be locally switched on the same VLAN as the AP, or on a different VLAN if available
on the trunk port.
For wireless clients’ traffic from a specific WLAN to be locally switched, at least two conditions must be met: the AP
mode must be FlexConnect and the option for FlexConnect Local Switching must be checked under the FlexConnect
settings of the WLAN’s Advanced tab options, as shown in Figure 4-3.
139
||||||||||||||||||||
||||||||||||||||||||
Figure 4-3 FlexConnect Local Switching Enabled Under the WLAN’s Advanced Tab
The snapshot shows the following options with a checkbox to enable: FlexConnect Local Switching, (enabled)
FlexConnect Local Auth, Learn Client IP Address (enabled), Vlan based Central Switching, Central DHCP
Processing, Override DNS, NAT-PAT, and Central Assoc.
If the AP is in FlexConnect mode but FlexConnect Local Switching is not enabled under the WLAN, data traffic is
centrally switched through the WLC, just as if the AP was in local mode. We can also refer to this scenario as
(FlexConnect) central switching.
On top of central and local switching modes, we can also distinguish two options for authenticating wireless clients. We
speak about central authentication when the WLC itself handles authentications, either through the internal database or
more commonly by communicating with an external RADIUS server. Conversely, local authentication refers to the AP
managing authentications against its local database, or acting as a NAD/AAA client for an external RADIUS server.
Central authentication is the most commonly used option and the only one supported for APs in local or Bridge mode.
For FlexConnect (or even Flex+Bridge) APs, you can deploy both, although central authentication is still the
recommended one, while keeping local authentication as a fallback.
Mobility Express
Although an official “Cisco Mobility Express Deployment Guide” exists, we want to spend few paragraphs
reintroducing this more recent architecture, because we think that additional clarifications on this topic could still
benefit CCIE Wireless candidates.
Mobility Express, sometimes abbreviated ME, is the newest deployment type, and you can think of it as a vWLC
running on an AP. Well, almost. The main goals for ME are simplicity and ease of use, so compared to a vWLC, some
menus and features are not supported and not displayed on purpose. The general rules with ME are that whatever is
available through the GUI is supported, and features listed in the official command reference guide are supported too:
https://www.cisco.com/c/en/us/td/docs/wireless/access_point/mob_exp/83/cmd-ref/me_cr_book.html
140
Technet24
||||||||||||||||||||
||||||||||||||||||||
For all the configuration and monitoring tasks, the Master AP communicates with other APs of the same Mobility
Express deployment through the standard CAPWAP control tunnel. Data traffic for wireless clients is locally switched
directly on the switch port behind each AP, the Master AP’s one included. This corresponds exactly to the same
behavior as for FlexConnect local switching when deploying a dedicated physical/ virtual WLC.
141
||||||||||||||||||||
||||||||||||||||||||
142
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figure 4-5 Master AP’s State Machine for Initial Boot and Configuration
The flowchart begins with a decision symbol, Can I get an IP via DHCP? If yes, it leads to another decision
symbol, Can I discover a Master AP/WLC and register? If yes, the second decision leads to a process symbol
Register to the already available WLC or Master AP. If no, both the decision symbols lead to a process symbol
SSID CiscoAirProvision enabled and management IP 192.168.1.1 available over the wireless only.
The SSID CiscoAirProvision is protected with WPA2 PSK and the passphrase is “password”.
After entering the “password” password (apologies for the wording joke) and getting connected to the SSID
CiscoAirProvision, your machine should obtain an IP address in the 192.168.1.0/24 network; as part of the initial
configuration process, in fact, the Master AP automatically enabled an internal DHCP server too.
If you open a web browser and try to access any website, you should automatically be redirected to the following URL:
http://mobilityexpress.cisco/screens/day0-config.html. If you are not automatically redirected (web browsers may cache
already visited pages or may not accept untrusted certificates redirections), you can always access the initial setup
wizard directly at http://192.168.1.1. From here, the initial configuration steps are intuitive and easy to complete.
Note
The setup wizard proposes to configure WLANs with corresponding DHCP pools and servers, which could run locally
on the Master AP or on external DHCP servers. A mix of DHCP pools from the Master AP’s internal DHCP server and
pools from external DHCP servers is not supported. If you enable an internal DHCP pool for the Management Network,
for example, you must keep using internal DHCP pools for your WLANs too.
After setting up the Master AP, additional access points can discover and register to it. As compared to a “standard”
(v)WLC, the only discovery process supported with Mobility Express is through L2 broadcast requests on the same
subnet, where the AP obtains an IP address. For such a reason, new APs should be connected to the same management
VLAN as the one where you originally connected the Master AP.
A new AP registering to the Master AP, if it is not already running the same version, needs to download the same image
version as the Master AP. The Master AP does not store AP images in its flash memory. As shown in Figure 4-6, when
a new AP needs to update its image, the Master AP first downloads the new AP’s image via TFTP and then provisions
the newly registered AP with such an image. These two phases run almost in parallel.
143
||||||||||||||||||||
||||||||||||||||||||
Figure 4-6 The Master AP Provisions Newly Registered APs with Updated Images via TFTP
The illustration shows a 2800 Master AP connected to a T F T P server and 3702 AP (new AP) via a parallel
connection. The newly registered AP downloads the image via the master AP. The Master AP downloads the
new APs image via T F T P and it pushes the image to the new A P.
As of version 8.3, if the Master AP can join Cisco.com, you can also push software updates directly from Cisco.com to
all the 1800/2800/3800 APs of your Mobility Express deployment. Other AP models, if deployed, would still need to go
through the TFTP procedure.
If the originally designated Master AP is not reachable anymore, its role can be taken over at any time by another
1800/2800/3800 series AP of the same Mobility Express deployment, except for the 1810 series APs.
The Master AP and its backup(s) do not need to be of the same model; they can be any mix of 1800/2800/3800 APs,
but it is generally recommended to keep the same model for consistency.
Note
Up to AireOS 8.3, Mobility Express is limited to 25 APs, so any 1800/2800/3800 series AP will support the Master AP
role with the same scaling numbers. Starting from AireOS 8.4, and as of 8.5, 1540, and 1800 series APs acting as a
144
Technet24
||||||||||||||||||||
||||||||||||||||||||
145
||||||||||||||||||||
||||||||||||||||||||
You can authenticate WLC administrators against the WLC’s internal database or even through an external
authentication server. Accounts created in the internal database can have read or read-write access to all of the WLC’s
tasks.
Note
To align with the jargon sometime used in the configuration examples, as shown in Figure 4-7, we refer here to the
WLC’s “tasks” as the main menu tabs on top of the graphical user interface (GUI): MONITOR, WLANs,
CONTROLLER, WIRELESS, SECURITY, MANAGEMENT, COMMANDS.
Figure 4-7 Menu Tabs on a WLC Also Known as “Tasks” for Admin User Authorization
If instead of the WLC’s internal database you would like to authenticate management users through an external
database, you can configure admin access through a RADIUS or a TACACS+ authentication server.
When authenticating admin users via RADIUS, the types of privileges you can assign them are the same as for users
from the WLC’s internal database: you can distinguish between read-only or read-write access. The authentication
server can assign read privileges by returning the IETF RADIUS attribute “[6] Service-Type” with a value of 7 for NAS
Prompt in the final Access-Accept response. For read-write privileges, a value of 6 for Administrative should be passed
back in the same RADIUS attribute.
Additional configuration details can be found in the “RADIUS Server Authentication of Management Users on Wireless
LAN Controller (WLC) Configuration Example”:
https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wlan-security/71989-manage-wlc-users-radius.html
When authenticating admin users via TACACS+, on top of read-only or read-write access privileges, you can also
specify which “tasks,” or main menus, the admin user has write access to. The authentication server can pass back
TACACS+ custom attributes in the form of role1, role2, role3, and so on, with values corresponding to the equivalent
tasks the user should have access to: MONITOR, WLANs, CONTROLLER, WIRELESS, SECURITY,
MANAGEMENT, COMMANDS, ALL, and LOBBY. For example, if you would like to grant write access to the
WLANs and SECURITY tasks, the TACACS+ server should pass back the following attributes:
role1=WLAN
role2=SECURITY
Note
There is no mistake in the example; for the WLANs task on the WLC, the TACACS+ attribute should contain the value
146
Technet24
||||||||||||||||||||
||||||||||||||||||||
147
||||||||||||||||||||
||||||||||||||||||||
To filter control plane traffic to/from specific networks or even IP addresses, you can additionally configure CPU
ACLs. The WLC’s CPU handles protocols for management access, CAPWAP control traffic, RADIUS, DHCP, and so
on, and traffic to the CPU is defined as all traffic destined to any of the WLC’s interfaces (management, ap-manager,
dynamic and virtual), as well as to the service port. Traffic between wireless clients or between wireless and wired
clients is not handled by the WLC’s CPU but by the data plane, and should be filtered through ACLs applied to the
dynamic interface, the WLAN, dynamically assigned via RADIUS or through a local policy too.
Note
Traffic between wireless clients tunneled to an anchor WLC and the rest of the wired network behind that anchor is
carried through an Ethernet over IP (EoIP) tunnel from the foreign WLC to the anchor WLC. The EoIP tunnel is
established between the management interfaces of the two WLCs; therefore, although we are talking about traffic
between wireless and wired clients, a CPU ACL not allowing EoIP tunnels between the two WLCs would automatically
block traffic between wireless and wired clients too.
To configure a CPU ACL, you first need to create an ACL under SECURITY > Access Control Lists > Access
Control Lists and then apply that ACL to the CPU itself under SECURITY > Access Control Lists > CPU Access
Control Lists.
The direction of an ACL’s rule (inbound or outbound) is not taken into account when applied to the CPU: for example,
to block traffic from the 192.168.1.0/24 network, in the ACL’s rule you can configure that network as the source, leave
all other options (for example, destination, protocol, direction) to any, and set it to deny.
148
Technet24
||||||||||||||||||||
||||||||||||||||||||
Even before configuring CPU ACLs, you may want to consider options to allow or block management access for
wireless users or even for managing the WLC through one of its dynamic interfaces’ networks.
Management Via Wireless is disabled by default and can be configured under MANAGEMENT > Mgmt Via Wireless
> Management Via Wireless. Even when disabled, wireless clients connected through the WLC can open connections
for management protocols (for example, SSH, HTTPS, and so on) enabled on that WLC, and also get to the SSH login
prompt, for example (the session will anyway be blocked when attempting to log in). For such a reason, when blocking
management access for wireless users, a CPU ACL should also be deployed on top.
For ease of management, however, sometime you may want to have a dedicated WLAN or subnet through which you
can access the WLC while being connected to your APs and verify your wireless deployment, for example. In such a
case, you could enable Management Via Wireless, assign your management users to a dedicated subnet, and then allow
that subnet on a CPU ACL, while denying traffic for other wireless users’ networks on that very same ACL.
Note
Management Via Wireless is a global setting. When enabled, and without a CPU ACL, any wireless user with the right
admin credentials can gain management access to the WLC through the management interface or the service port
(assuming that the needed switching and routing infrastructure is configured accordingly). Through a CPU ACL you can
filter management access through specific networks only. A wireless management user could connect through a
dedicated WLAN associated to that specific network. Alternatively, while connecting through the same 802.1X-enabled
WLAN as for other users, for example, through RADIUS attributes you can dynamically assign management users to
the management VLAN/subnet allowed on the CPU ACL.
Management Via Dynamic Interface is also disabled by default and can be configured via command line interface (CLI)
only, through the following command:
Click here to view code image
config network mgmt-via-dynamic-interface [enable | disable]
149
||||||||||||||||||||
||||||||||||||||||||
The management interface is the first one you need to configure when installing a WLC. As the name says, it provides
management access to the WLC but also CAPWAP discovery responses to the APs, as well as communication with
other WLCs and external resources.
Before trying to register to a WLC, an AP needs to discover that WLC through its management IP. The AP learns a
WLC’s management IP in many ways: via DHCP option 43, through DNS resolution, trying a L2 broadcast discovery,
and others. The WLC replies to a discovery request on its management IP by sending back a response with the
information of the AP-manager interface’s IP, which is the one the APs will use to register and exchange CAPWAP
traffic with.
This separation between management and AP-manager interfaces was probably more intuitive in the past, when the
WLC required configuring one management interface and one separate AP-manager interface. Since some years and
some AireOS versions, the management interface carries the role of AP-manager too, so this separation between the
two interfaces is less explicit, although logically still present. By default we were using the same physical port (or just all
ports in case of LAG) for both the manager and AP-manager interfaces, but other ports could be used under the
condition of creating a new dedicated AP-manager interface for each of those ports. Nowadays we tend to keep just one
AP-manager interface, corresponding to the management one, and to use either just one port or LAG.
If you want to assign one or more (dynamic) interfaces to other ports than the management interface’s port, each one of
those other ports must have a dynamic interface enabled for Dynamic AP Management (that is, with an AP-manager
role). Figure 4-9 shows the option to enable the AP-manager role on a dynamic interface.
150
Technet24
||||||||||||||||||||
||||||||||||||||||||
The screenshot shows the Controller menu selected from the main menu tabs at the top. Interfaces option under
the controller menu is selected. The Interfaces Edit page shows the following sections: General Information,
Configuration, NAT Address, Physical Information, and Interface Address. Under General Information,
Interface Name and MAC Address details are present. Under Configuration, Guest Lan checkbox and NAS-ID
field box are present. Under NAT address, Enable NAT Address checkbox is present. Under Physical
Information, Port Number field box (1) Backup Port field box (0), Active Port field box (1), and Enable
Dynamic AP Management checkbox (selected) are present. Under Interface Address, VLAN Identifier and IP
Address field boxes are present.
The management interface has the option Dynamic AP Management enabled by default. If you configure LAG, only
one interface can act as the AP-manager, and that will be the management interface by default.
When using an interface as an AP-manager with Dynamic AP Management enabled, you should not configure any
backup port. Backup for AP-manager interfaces on multiple ports should be implemented implicitly by the requirement
to have an AP-manager per port already.
In your daily job as a wireless expert you might encounter organizations asking for the APs to communicate with the
WLC through a dedicated IP on a dedicated port only, which should be physically separated from the management
interface and port. This is not completely possible: APs must be able to initially reach the WLC’s management IP, at
least for the very first discovery phase, so at that point going through an AP-manager on a different port might not make
151
||||||||||||||||||||
||||||||||||||||||||
Service Port
If the service port is supported by the WLC model in use, it is another interface that the initial WLC’s setup wizard asks
you to configure. If you don’t plan to use any, you can simply define a bogus IP (on a completely different super-net
from the management interface) and keep the option for a DHCP assigned address disabled.
The service port was originally designed to provide out-of-band management to the WLC’s GUI or CLI. Since AireOS
8.2, the service port also supports SNMP and SYSLOG traffic, as well as download and upload operations. The IP
address of the service port should always be on a different super-net from the management interface’s IP. For example,
if the management IP is configured as 10.10.0.250 in the 10.10.0.0/24 network, the service port’s IP could be something
152
Technet24
||||||||||||||||||||
||||||||||||||||||||
Virtual Interface
The virtual interface is another interface that the WLC’s installation script asks you to configure during the initial setup.
A common convention in the past was to use odd enough, nonrouted IP addresses such as 1.1.1.1, 2.2.2.2, 3.3.3.3, and
so on. Since then, address ranges in networks such as 1.0.0.0/8, 2.0.0.0/8, and 3.0.0.0/8 have been allocated by IANA to
specific organizations. Following the RFC 5737, the current recommended best practice is to use an IP from blocks used
for documentation, such as the IP 192.0.2.1 from the 192.0.2.0/24 network.
Controllers verify whether they have the same virtual IP in order to successfully exchange mobility messages. This is
one first prerequisite if you plan to deploy WLCs in the same mobility domain or mobility group.
Another usage of the virtual IP is to host the WLC’s internal web server for all web redirection scenarios based on
Local Web Authentication (LWA). With a web redirect enabled WLAN, no matter if for web authentication or simply
web passthrough, users go through the WLC’s internal web server hosted on the virtual interface. When using HTTPS
for web redirections, enabled by default under MANAGEMENT > HTTP-HTTPS > WebAuth SecureWeb, the WLC
presents a dedicated certificate tied to the virtual IP or FQDN (if configured). This plays an important role when
deploying a publicly signed certificate for the virtual interface. Such a certificate should be issued with the virtual IP in
the certificate’s common name, or else with the virtual interface’s FQDN (if configured) in the common name plus the
virtual IP in the subject alternative name (SAN) IP and DNS options.
Note
When using a publicly signed certificate for this purpose and using a FQDN in a certificate’s CN (also configuring it at
the WLC for the virtual interface), the wireless clients are redirected to the WLC’s internal web server by the WLC
giving the URL of the virtual interface using the FQDN instead of the IP address. Hence, clients should be able to
perform DNS resolution for the virtual IP with their DNS server(s), even though that may mean adding a public DNS
entry pointed to a private address, which can be counterintuitive to some enterprises.
If not publicly signed, such a certificate is automatically generated as a self-signed one during the initial WLC’s
installation, with the first virtual IP that you specify through the setup wizard as the common name of that certificate.
You can of course modify the virtual IP and FQDN later on (you need to reboot the WLC for the new virtual IP/FQDN
to be applied), but the self-signed certificate will keep the initially configured virtual IP in the common name until you
regenerate such a certificate under SECURITY > Web Auth > Certificate (a WLC’s reboot is needed for the new
certificate to take effect).
One more function of the virtual interface is as a placeholder for the DHCP server IP when DHCP proxy is enabled
(globally or at the dynamic interface level).
Dynamic Interfaces
Although you can associate a WLAN with the management interface, you usually may want to assign your wireless
clients to a different VLAN. This is the main purpose of a dynamic interface: switching traffic of a specific WLAN or
client on the corresponding VLAN. Even if the WLC is not a routing device and simply switches client traffic on
different VLANs, you still need to reserve an IP for the WLC on the needed VLAN when configuring the corresponding
dynamic interface. A dynamic interface can be assigned to a specific port, or to all ports through LAG. If DHCP proxy
is enabled on the WLC, DHCP requests from clients assigned to a dynamic interface are proxied through that dynamic
153
||||||||||||||||||||
||||||||||||||||||||
Where <VLAN ID/Name> could be either the VLAN number of the dynamic interface that you want to assign or
the dynamic interface’s name itself.
For a FlexConnect locally switched WLAN, wireless clients are automatically locally switched with the same VLAN ID
as the one configured under the dynamic interface associated to the WLAN, so you should make sure that the correct
VLAN IDs are also configured on those switches, where FlexConnect APs are connected.
For FlexConnect locally switched clients to be on a different VLAN, you can “remap” the WLAN to a different VLAN
under each AP’s FlexConnect settings, or through the WLAN-to-VLAN mappings of a FlexConnect Group, to which
you can assign your FlexConnect APs. In this case you do not need to create a dynamic interface for each VLAN on
154
Technet24
||||||||||||||||||||
||||||||||||||||||||
For higher bandwidth capacity and interfaces availability, you can aggregate ports of a WLC to a single logical link. The
WLC partially implements some of the features from the IEEE 802.3ad standard for Link Aggregation Control Protocol
(LACP); however, it does not completely implement the full standard: some features, such as dynamic link negotiation,
are not supported. When you configure the interfaces of a Cisco switch for participating to the port-channel, where the
WLC is connected, you should force the EtherChannel mode with the command channel-group <id> mode on. Since
the WLC also relies on the switch for the traffic’s load-balancing technique, the recommended option for load balancing
is based on source and destination IP: on a Cisco Catalyst switch you can configure this with the global command port-
channel load-balance src-dst-ip. You can also use LAG with Virtual Switching System (VSS) and Nexus virtual Port-
Channel (vPC).
When you enable LAG on the WLC, a reboot is required for changes to take effect; after that, all interfaces will be
mapped to a single logical port, ephemerally numbered 29 on the WLC itself.
As previously mentioned when describing the AP-manager interface, if LAG is enabled there can be only one interface
carrying the AP-manager role, and by default the management interface is the one. On top of increased bandwidth, you
may usually want to implement LAG for ports redundancy. This may not apply if you need to connect the WLC ports to
different, nonstacked switches, for example.
||||||||||||||||||||
||||||||||||||||||||
When connecting an access point to a switch port, you may want to configure additional options to authenticate the AP
on the network and/or even at the WLC level during/after the join process.
One first level of authentication could be directly through 802.1X on the access switch, where the AP is connected.
IOS-based APs support an 802.1X supplicant for the wired/uplink interface. The Extensible Authentication Protocol
(EAP) method is EAP-FAST as the tunneling technique, with MS-CHAPv2 as the inner method. The authentication is
therefore based on username and password, which you can configure either via CLI on the AP (through the command
capwap ap dot1x username [USER] password [PWD] in enable mode, on IOS APs) or through the WLC’s CLI/GUI,
for all APs at once, or AP by AP, as shown in Figure 4-10.
156
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figure 4-10 Example for Configuring 802.1X Credentials at a Single AP Level Through the WLC’s GUI
The screenshot shows the Wireless menu selected from the main menu tabs at the top. Access Points section
under Wireless menu is expanded to reveal: All APs, Radios, and Global configuration. Radios is expanded to
list: 802.11a/n/ac, 802.11b/g/n, and Dual-Band Radios. FlexConnect Groups section lists: FlexConnect ACLs,
FlexConnect VLAN, and Templates. A page titled Details for AP-3702I.fcc4 shows six tabs from which
Credentials is selected. The Credentials tab shows two sections: Login Credentials and 802.1x Supplicant
Credentials. Under Login Credentials, Over-ride Global Credentials checkbox is present. Under 802.1x
Supplicant Credentials, Over-ride Global Credentials checkbox and the following field boxes are present:
Username, Password, and Confirm password.
Pushing the 802.1X credentials through the WLC implies that the AP must register to the WLC first. The AP should use
802.1X to authenticate to the network even before registering to the WLC, but you could also consider pushing the
802.1X credentials to your APs as a prestaging operation, before activating 802.1X on your switch ports in closed
mode, for example.
Note
Unlike IOS APs, COS APs did not support the 802.1X supplicant for wired authentication before AireOS 8.6.
802.1X credentials are stored in the AP itself and encrypted with a type 7 password hash. Because this encryption
option is relatively easy to decrypt, someone with physical access to the AP’s console port and with the right login
credentials could potentially retrieve the 802.1X username and password.
Common best practices to prevent and mitigate this risk include changing the AP’s login credentials to something more
secure than the default “Cisco/Cisco/Cisco” (for login user/password/enable). Another option is to make sure that the
network (for example, the VLAN, subnet, VRF, and so on) where APs are deployed restricts communications to the
WLC and other minimum required resources but filters access to any other unneeded resource. If someone manages to
use the same AP’s 802.1X credentials on other devices, he or she would be limited to CAPWAP traffic to or from the
WLC, for example, where additional filtering and authorization techniques could be applied on top. To exploit a feature
seen at the beginning of this chapter, you can also configure CPU ACLs for extra control on CAPWAP traffic from the
AP’s network to the WLC.
When an AP discovers and tries joining a WLC, you can also enable authorization options for the AP’s certificate type
or its MAC address. On the WLC, under Security > AAA > AP Policies, you have the choice of authorizing APs
157
||||||||||||||||||||
||||||||||||||||||||
158
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
AP Modes of Operations
After connecting successfully to the network, lightweight APs can automatically discover and register to a WLC
through different options, such as broadcast, DHCP, DNS, or other discovery techniques. Although this is a
fundamental process, we will not cover it in this book in depth because a very well detailed description is already
available in the official “Enterprise Mobility 8.1 Design Guide”:
https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-1/Enterprise-Mobility-8-1-Design-
Guide/Enterprise_Mobility_8-1_Deployment_Guide/cuwn.html#pgfId-1259523
An out-of-the-box AP by default will join a WLC in the so called “local” mode. As discussed at the beginning of this
chapter, the local mode allows the AP to switch all the wireless clients’ traffic centrally through the WLC, which will
bridge this very same traffic to specific VLANs if needed. As a general rule, the local mode is the one that supports the
broadest spectrum of features. To change the AP mode you have the following options:
After the AP joins the WLC: This is the most classic approach, and you can modify the AP mode either through
the WLC’s GUI/CLI or even with an external management tool for multiple APs at the same time, such as with
Cisco Prime Infrastructure, via SNMP.
To change the AP mode through the WLC’s GUI, as shown in Figure 4-12, you can browse under WIRELESS >
Access Points > All APs and click the AP of your choice.
160
Technet24
||||||||||||||||||||
||||||||||||||||||||
The general tab is selected and it shows a section titled General. Under the section, the AP Mode spin box
is clicked to reveal a list: local, FlexConnect (selected), monitor, Rogue Detector, Sniffer, Bridge,
Flex+Bridge, SE-Connect, and Sensor.
Before the AP joins the WLC: Through the APIC-EM PnP solution described in the previous section, an AP could
download a configuration file with its operating mode before joining the WLC. In this case, the AP mode you can
push beforehand is the FlexConnect one.
Automatically, when the AP joins the WLC: You can configure the WLC to automatically convert APs joining it
to either FlexConnect or Monitor mode, through the following command line:
161
||||||||||||||||||||
||||||||||||||||||||
This option is not available via GUI and is supported on the following controller models: 7510, 8510, 5520, 8540,
vWLC.
FlexConnect is the mode to switch traffic locally, at the AP’s level, and bridge it directly on a VLAN of the switch port,
where the AP is connected. This mode also adds some “survivability” options to the AP: if connectivity to the WLC is
lost, locally switched clients already connected to a WLAN can stay connected, at least until the next (re)association,
and new clients can connect under some conditions. To switch clients locally, on top of the AP in FlexConnect mode,
you need to enable FlexConnect Local Switching on the wanted WLAN too.
Since AireOS 8.2, when changing the AP mode from local to FlexConnect, the AP does not need to reboot anymore.
Other changes in the AP mode, for example from FlexConnect back to local or any other combination, require the AP
to reboot.
Monitor mode is another option that has been available for many years to set the AP in a “listening” operational status.
An AP in monitor mode does not serve any wireless client and keeps cycling through different wireless channels to scan
for rogue APs, attacks, RRM stats (such as Channel Utilization), and interferences (if supported by the AP model).
Channels, which a monitor mode AP should cycle through, can be just those allowed for Dynamic Channel Assignment
(DCA), those allowed by the Country code configured for the AP, or all channels. As shown in Figure 4-13, you can
configure this for the 2.4 GHz or 5 GHz band under WIRELESS > 802.11a/n/ac or 802.11b/g/n > RRM > General.
This setting applies to all AP operational modes, not just to monitor mode APs.
Figure 4-13 Example of Monitoring Channels Configuration for the 5 GHz Band
The screenshot shows General option, under RRM sub-section of 802.11a/n/ac section, under Wireless menu
selected. Under Profile Threshold for Traps, the following fields are listed: Interference (0 to 100 percent),
162
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Figure 4-14 Example of the Mesh Settings Activated After Configuring the Bridge Mode on the AP
The following tabs are present at the top: General, Credentials, Interfaces, High Availability, Inventory, Mesh
(selected), and Advanced. The settings of the mesh tab are as follows: AP Role spin box is set to MeshAP,
Bridge Type, Bridge Group Name field box, Strict Matching BGN checkbox, Ethernet Bridging checkbox
(selected), Preferred Parent field box reading none, Backhaul Interface, Bridge Data Rate (Mbps) spin box is
set to auto, Ethernet Link Status, PSK Key TimeStamp, VLAN Support checkbox. Delete PSK button is
present. Mesh RAP Downlink Backhaul section shows RAP Downlink Backhaul option set to the radio button,
5 GHz. Enable button is present.
Mesh is used to interconnect APs through a wireless backhaul instead of a standard wired Ethernet one. At least one
AP, called the Root AP, must have wired connectivity to forward traffic to the uplink backend network. Other APs
without wired connectivity can associate to the Root AP (or between them) via either the 5 GHz band (the default
behavior) or the 2.4 GHz one, and use this radio link as their uplink to the rest of the network. These APs are referred to
as Mesh APs in the WLC. Although technically all APs can communicate with each other for calculating and building
the mesh backhaul, at any specific point in time an AP won’t be communicating with all other APs at the same time.
Mesh APs negotiate an optimized “path” to the Root AP, and recalculate such a path dynamically if conditions change
(for instance, a MAP becomes unavailable, a DFS event is triggered, an interference occurs, and so on). Because of this
capacity of all APs communicating with one another, the term mesh is used.
164
Technet24
||||||||||||||||||||
||||||||||||||||||||
165
||||||||||||||||||||
||||||||||||||||||||
Figure 4-15 Example of an SE-Connect AP’s General Details, with the Key for Analysis Tools
The general tab shows three sections: General, and GPS Location. The general section lists the following: AP
Name field box reading AP-2702I.e7f0, Location field box reading default location, AP MAC Address, Base
Radio MAC, Admin Status spin box set to Enable, AP Mode spin box set to SE-Connect, AP Sub Mode spin
box set to None, Operational Status, Port Number, Venue Group spin box is set to Unspecified, and Venue
Type spin box is set to Unspecified. Three buttons, Add New Venue, Venue, and Language Name are shown.
166
Technet24
||||||||||||||||||||
||||||||||||||||||||
Lightweight APs are mainly managed through the WLC, which is the device pushing the vast majority of the
configuration parameters. You can still configure some settings on the APs directly via CLI, mainly for options such as
a static IP, or even primary, secondary, and tertiary WLC IPs. As seen in the previous subsection, 802.1X credentials
can also be configured via CLI on the AP directly. To generalize these concepts a bit more, we could say that the AP’s
CLI provides you with the needed commands to manually connect an AP to the network and register it to the WLC.
All the details on other useful commands for a lightweight AP’s CLI are documented in the official “Cisco Wireless
Controller Command Reference”:
https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3/command-reference/b-
cr83/miscellaneous_commands_2.html
IOS-based lightweight APs still allow you to access all the CLI commands available for autonomous APs. You can
achieve this through the command debug capwap console cli in enable mode (the command is hidden, so autocomplete
through the tab key does not apply). From here, you could theoretically use any other command available for
autonomous IOS APs. On top of not being officially recommended or supported, commands for the autonomous mode
applied in lightweight mode through this technique do not survive a hardware reset of the AP. Thanks to this option you
can still force some operations, such as a reimage, an upgrade, or even a conversion of the AP from lightweight to
autonomous. The following command sequence shows an example of how to push a new image file for these use cases:
Click here to view code image
ap# debug capwap console cli
ap# archive download-sw /force-reload /overwrite tftp://TFTP_Server_
IP/Image_File_Path
Note
COS APs do not support the debug capwap console cli command because there are no IOS commands or autonomous
mode for these APs.
The WLC pushes all other AP’s parameters for nominal wireless operations. All features that you can configure through
167
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
169
||||||||||||||||||||
||||||||||||||||||||
Figure 4-16 Example of Options for Displaying the Second-Strongest APs Coverage on a Map with Ekahau
The snapshot shows an option visualization mode: smooth or detailed; a scale set to 2m; a slider set to very;
signal prediction with five options: off, current floor, plus or minus floor, plus or minus 2 floors, and all floors;
adapter spin box set to Raw Measurements; Show the spin box set to second strongest; and signal at spin box
set to all channels.
Cisco provides software-based features in the WLC, through Radio Resource Management (RRM) algorithms, to allow
APs to increase their transmit power levels when they identify a coverage hole. The rules under which a coverage hole
event is triggered depend on many factors, and the WLC might not necessarily always increase the transmit power of an
AP, if that would cause co-channel interferences with other APs, for example. For such reasons, on top of relying on
RRM’s coverage hole detection in software, you may want to consider planning for radio redundancy right from the
170
Technet24
||||||||||||||||||||
||||||||||||||||||||
The more legacy high availability (HA) model for WLCs is what has often been referred to as N+1, or even also N+N.
We could generalize it as N+X, with X greater than or equal to 1 (and usually less than or equal to N, although
technically not necessary). The first N refers to your primary WLCs, among which you distribute your lightweight APs.
The second digit after the plus sign (1, N, or another X) represents the number of secondary controllers ready to take
over the APs from one or more of the primary WLC(s) in case of failure.
This notation is mainly used to indicate the number of backup controllers, and sometimes we just keep the first N as is,
without necessarily specifying the number of primary controllers. We could, for example, state that we deployed 3+2
controllers to say that there are 3 primary and 2 secondary WLCs. Or we could also say that we deployed 3 controllers
with an N+2 HA model, as a “synonym” to describe that there are 2 secondary controllers for backup.
You may want to achieve redundancy with an N+1, an N+2, or an N+3 or more HA model. There is not necessarily a
fixed rule for how many secondary controllers you should deploy. To push this concept a bit further, we could, for
instance, have just one 5508 WLC as primary with four 2504s as secondary WLCs, and we would talk about a 1+4 HA
model. Point taken, this might not be one of the most common scenarios; we just used an exception as a further example
of the theory.
Sometimes, if tertiary controllers are deployed, we could even start using the N+X+Y notation: for example, N+1+1
would indicate that we deployed a secondary and a tertiary WLC, N+3+2 would describe a deployment with three
secondary and two tertiary WLCs, and so on.
171
||||||||||||||||||||
||||||||||||||||||||
172
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Cisco was the first vendor on the market to introduce full stateful redundancy features for both APs and clients. AireOS
7.3 supported the initial version of stateful switch over (SSO) for APs, and AireOS 7.5 started supporting SSO for clients
too.
SSO is configured between two controllers only, one acting as primary/active and the other as secondary/standby. The
term stateful points to the fact that an AP’s or client’s session is fully replicated from the active to the standby WLC. In
case of failover, the standby WLC is ready to seamlessly take over APs and clients with almost no interruption in their
communications. We carefully use the adverb “almost” here, because clients may experience some minor latency for
some traffic categories. Nevertheless, no connectivity is lost: APs do not need to register again and clients must not
reassociate, reauthenticate, or go through DHCP again to obtain a new IP address. This solution presents major benefits
for APs and wireless clients, but it also contributes to not overload network services behind the WLCs in case of a
failover. Because APs and clients do not need to go through registration, authentication, or even DHCP again, for
example, those network services do not risk being called into play all of a sudden and for many APs/clients
concurrently. For instance, RADIUS servers do not need to reauthenticate all wireless clients at once because a WLC
failed and those clients had to reconnect altogether.
Sometime we also refer to the active and standby WLCs as a “pair.” When configured for SSO, the two controllers
share the same management IP and are seen by the rest of the network as one single device.
AP/Client SSO has been enhanced with additional features through different AireOS versions; you can find all the
details of such functionalities in the official “High Availability (SSO) Deployment Guide”:
https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-1/HA_SSO_DG/High_Availability_DG.html
We will hereafter list some of the main characteristics of AP/Client SSO, while leaving all other configuration details to
the aforementioned official guide:
Controllers of an SSO pair need to be of the same HW models among the following: 5500, 7500, 8500, and WiSM2
series WLCs. The more recent 3504 series WLC supports AP/Client SSO too.
Round trip time (RTT) latency between management IPs of the active and standby WLC should not exceed 80
milliseconds by default.
The bandwidth between the two controllers should be of at least 60 Mbps.
Only sessions for connected clients in the RUN state are synchronized between active and standby WLCs, and as of
AireOS 8.0, the sleeping client cache is replicated too. Clients in other states (for example, 802.1X_REQD,
DHCP_REQD) have to go through a new association in case of failover.
You must configure the management IPs from both the active and standby WLC on the same subnet/VLAN for
SSO to be supported.
The choice between keeping the controllers on the same Layer 2 or separating them across Layer 3 boundaries
could sometimes be one of the main decision factors when evaluating the N+1 HA model or SSO.
SSO requires the two controllers to communicate through an additional dedicated port, called the Redundancy Port
(RP), as well as to create another logical interface, called the Redundancy Management Interface (RMI), on the
same subnet/VLAN as the regular management interface.
175
||||||||||||||||||||
||||||||||||||||||||
RF Profiles
The first tool you may consider to assign different radio settings to different sets of APs are RF profiles. They were
introduced as of AireOS 7.2 with the purpose of differentiating RRM parameters on a per AP Group basis.
You can configure RF profiles under WIRELESS > RF Profiles, where you might already see that some default
profiles are already automatically created for low, typical, or high client density.
When creating a new RF profile, you first need to choose whether it applies to the 2.4 GHz or the 5 GHz radio, and then
you can optionally make it inherit settings from one of those pre-canned profiles. Each profile allows customizing
parameters for data rates, RRM algorithms, high density features, and client load balancing options, as shown in Figure
4-18.
176
Technet24
||||||||||||||||||||
||||||||||||||||||||
177
||||||||||||||||||||
||||||||||||||||||||
AP Groups
As seen in the previous paragraphs, AP groups are tightly related to RF profiles because you apply those profiles under
the AP groups’ configuration directly. However, AP groups were originally introduced to customize some WLAN
settings for specific sets of APs. You can access them under WLANs > Advanced > AP Groups in the WLC’s GUI.
A default AP group is always present in the WLC’s configuration: all APs are assigned to this group by default, unless
you configure the Out-Of-Box AP group or push the AP group settings through APIC-EM PnP before the AP joins the
WLC. Through an AP group, you can configure which SSIDs are served by which APs, and optionally remap those
SSIDs to different dynamic interfaces from those configured under the WLANs settings themselves. Other tabs of an
AP group allow you to customize details for 802.11u, hyperlocation and ports/modules, for APs supporting them.
However, the main use case of an AP group is to define which APs are serving which WLANs and, optionally, to
reassign those WLANs to specific dynamic interfaces.
Only WLANs with an ID of 16 or lower are assigned to the default AP group and cannot be unassigned from it. Other
WLANs with a higher ID cannot be assigned to the default AP group. Also, any other new AP group that you create
will not have any WLAN or any AP assigned to it by default.
By creating WLANs with an ID of 17 or higher, you can therefore prevent unwanted APs from automatically starting to
serve those WLANs when they first join the WLC. If all your WLANs have an ID of 17 or higher, you need to assign
those WLANs to a specific, nondefault AP group, for them to be served by your APs; your APs need to be manually
assigned to that same AP group too. We already mentioned this technique when describing options for AP authorization
through one of the previous sections, but you could find it useful for SSID planning too. Different zones or sites
exploiting the same wireless infrastructure might have separate needs for which SSIDs should be served in which area,
and AP groups could help you achieve this kind of goals.
In a similar way, you may want to map clients of the same SSID to different VLANs according to the zone they connect
from. Although you could support such a scenario with dynamic VLAN mapping via RADIUS attributes, a more
“static” option would be precisely through AP groups, as shown in Figure 4-20, especially if there is no RADIUS
authentication involved for clients of that SSID.
178
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figure 4-20 WLAN and Dynamic Interface Assignment Example Under an AP Group
The screenshot shows WLANs tab selected from the main menu tabs at the top. AP Groups option from
Advanced section under WLANs is selected. The Edit CCIE-AP-Group page displays the following tabs:
General, WLANs (selected), RF Profile, APs, 802.11u, Location, and Ports/Module. Add New button is present
at the top-right corner. A section titled Add New shows WLAN SSID spin box set to CCIE-SSID(20),
Interface/Interface Group (G) spin box set to vlan-111, and SNMP NAC State checkbox. Two buttons, Add
and Cancel are shown at the bottom. Below the section, the following tabs are present: WLAN ID, WLAN
SSID, Interface/Interface Group (G), and SNMP NAC State.
Previously, you could also remap a WLAN to a dynamic interface through an AP group to locally switch clients to the
dynamic interface’s corresponding VLAN if the WLAN (and the APs serving it) were set for FlexConnect. In this case
the dynamic interface’s VLAN didn’t necessarily have to exist centrally, behind the WLC, and the dynamic interface’s
IP could even be a bogus one. This dynamic interface mapping had the main goal of communicating to the FlexConnect
APs of the AP group the VLAN, on which to locally switch clients of that WLAN. Such a behavior originates by the
fact that, without any other “overriding” options, a FlexConnect locally switched WLAN by default bridges clients on
the same VLAN as the one from the dynamic interface assigned under the WLAN’s settings.
You can create multiple WLANs with the same SSID name, as long as they have different IDs (equal to or greater than
17) and profile names. Although today you can rely on standard IETF RADIUS attributes, such as the [32] NAS-
Identifier or the [30] Called-Station-Id, to determine from which AP group or WLAN the client is connecting, in the
past the only available option was the Cisco Vendor Specific Attribute (VSA) Airespace-Wlan-Id. By looking at the
WLAN ID number from the Airespace-Wlan-Id attribute in RADIUS requests from the WLC, you could build
authentication and authorization rules on your RADIUS server based on the client’s location. The client’s location in
such a scenario would be the AP group, to which you could map a WLAN with the same SSID name as other WLANs
but a different WLAN ID and profile name. Based on the location (or AP group) the client was connecting from, you
might have wanted to dynamically assign different VLANs, ACLs, QoS parameters, and so on via RADIUS attributes.
As of today things got a bit easier thanks to options to include the AP group name directly in the RADIUS attribute [30]
Called-Station-Id, for example, but the technique we just described through WLAN IDs and AP groups was and still is a
valid one to support such use cases.
Although the following may not be some very common examples, we still prefer to clarify the behavior of AP groups for
some specific cases, because they could be less evident to troubleshoot if you find yourself in such scenarios:
179
||||||||||||||||||||
||||||||||||||||||||
180
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figure 4-21 Example of Configuration of the RADIUS Attribute [30] Called-Station-Id on the WLC and
Policies on Identity Services Engine (ISE)
The screenshot shows WLANs option under WLANs section of WLANs menu is selected. The Edit CCIE-
SSID page shows the following tabs: General, Security (selected), QoS, Policy-Mapping, and Advanced. The
sub-tabs are Layer 2 (selected), Layer 3, AAA Servers. The settings are as follows: Layer 2 Security spin box
set to WPA+WPA2 and MAC Filtering checkbox. Four sections are displayed: Fast Transition, Protected
Management Frame, WPA+WPA2 Parameters, and Authentication Key Management. The first section shows
Fast Transition spin box set to Adaptive, Over the DS checkbox (Selected), and Reassociation Timeout field
reading 20 seconds. The second section shows the PMF spin box set to disabled. The third section shows WPA
Policy checkbox, WPA2 Policy checkbox (selected), WPA2 Encryption option set to AES checkbox, and
OSEN Policy checkbox.
FlexConnect Groups
As the name already suggests, a FlexConnect group is mainly used to push FlexConnect parameters to a set of
FlexConnect APs at once. FlexConnect groups do not modify any radio configuration, which is reserved to AP groups
and RF profiles, if needed. The same AP can be a member of an AP group and a FlexConnect group; the two group
categories are independent.
The FlexConnect group’s settings override the WLAN’s configuration, for example, for mapping a WLAN to a different
VLAN from one of the dynamic interfaces assigned to the WLAN. By default, parameters under the FlexConnect tab of
a single AP directly override the FlexConnect group’s configuration. For the native VLAN ID and WLAN-to-VLAN
mappings of a FlexConnect AP, you can configure the FlexConnect group to take precedence by enabling the option
Override VLAN on AP under the WLAN VLAN Mapping tab of the FlexConnect group itself.
Other settings that you can dynamically push via RADIUS attributes (for example, VLANs, ACLs, and so on) have the
highest priority and override the configuration at the single AP’s level too.
181
||||||||||||||||||||
||||||||||||||||||||
To Layer 2 or To Layer 3?
When creating a WLAN, one of the first decisions you probably need to make is whether that SSID will be an open or a
secure one. We can define an open SSID as having no encryption. Although still supported, because WEP is nowadays
not recommended whatsoever, we could simplify this reasoning a step further and think of “open vs. secure” as “open
vs. WPA/WPA2 encrypted.” This first distinction determines the level of Layer 2 security of your SSID; it does not,
however, define the authentication method yet.
A very important point we should clarify from the beginning is that a secure SSID cannot fall back to open. For
instance, if an SSID is configured for WPA/WPA2 with 802.1X authentication, a client cannot connect anyway through
MAC authentication in case it doesn’t support any EAP method. For 802.1X on wired networks you may sometimes
have options on the switch allowing authenticating clients through MAC authentication bypass (MAB) if they don’t
support 802.1X. This is possible because on wired networks we don’t encrypt the wired communication between the
client and the switch. (Well, historically we didn’t, at least not before the introduction of IEEE 802.1AE with MACsec.)
On wireless networks, if we configure a secure WLAN with WPA/WPA2, the client must support encryption too. More
precisely, it must install a Pairwise Master Key (PMK) from which to derive other encryption keys. The PMK is
installed in two ways, either statically because it is derived from a passphrase (that is, a pre-shared key, or PSK), or
dynamically because it is assigned by a RADIUS server at the end of an EAP authentication. Without a PMK to derive
encryption keys from, a client cannot complete the association to a WPA/WPA2 secured SSID. On a WPA/WPA2
secured SSID configured for 802.1X, if the client didn’t support 802.1X, it could not obtain the PMK at the end of the
EAP authentication process and derive the encryption keys to connect. On wireless networks, there is no option to fall
back to open.
Another fundamental concept to keep in mind is that when you configure a secure SSID for WPA/WPA2, you can
choose either a PSK-based or an 802.1X-based Authentication Key Management mechanism, but not both under the
same WLAN. This means that you can support either statically assigned keys (through a passphrase, PSK) or
182
Technet24
||||||||||||||||||||
||||||||||||||||||||
183
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
To configure L2 and L3 security and authentication options of an SSID, you can browse under the corresponding
Security tab of your WLAN. As the menus present themselves, the Layer 2 subtab lists all the Layer 2 security and
authentication features, and the Layer 3 subtab contains the options to implement LWA.
Layer 2 security options allow choosing between an open and a secure SSID. For a secure SSID, probably the most used
encryption method is WPA+WPA2. As of today, the Wi-Fi Alliance is deprecating the use of WEP, and also of WPA
TKIP as the only cipher option for a WLAN. If you need support for WPA TKIP on an SSID, you need to enable
WPA2 AES too, for example.
AireOS 8.3 introduced the support for some security and QoS features co-developed with Apple, and more specifically
for Adaptive 802.11r. Roaming and key management techniques, such as 802.11r, are explained later in this chapter.
When you enable Adaptive 802.11r, sometime also referred to as Adaptive Fast Transition (FT), APs will include an
optional CCX Information Element (IE) in their beacons with a specific bit set to indicate support for 802.11r. This
CCX IE is understood by Apple devices only, which can then negotiate support for 802.11r in the association phase.
Other non-Apple devices not understanding such a CCX IE will not detect that the WLAN supports 802.11r, and they
will complete the association process without negotiating 802.11r. When choosing WPA+WPA2 as the Layer 2 security
option for your SSID and enabling at least a WPA2 cipher suite, Adaptive 802.11r is also automatically enabled by
default.
On top of cipher suite and Fast Transition options, in the same Layer 2 security subtab you can find settings to enable
different authentication key management methods for roaming, which are also covered later, along with some
documentation.
Through the Layer 3 security subtab you can configure Local Web Authentication (LWA) scenarios. By selecting Web
Policy in the Layer 3 Security drop-down menu, you have the option of selecting among several web portal redirection
flavors. You can find all the details on these different techniques, and how to configure them, in the following official
guide:
https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wlan-security/115951-web-auth-wlc-guide-00.html
185
||||||||||||||||||||
||||||||||||||||||||
Rogue Policies
On top of specific options in the WLAN’s configuration, you can add further security measures to your wireless
network by deploying policies to detect and mitigate rogue access points. The very definition of a rogue AP is an access
point not known by any WLC in the same RF group or mobility group. APs from your deployment forward information
about other detected APs to the WLC, and the WLC checks whether those newly detected APs are known through
another WLC in the same mobility group, or else because their RF neighbor messages heard by your APs included the
186
Technet24
||||||||||||||||||||
||||||||||||||||||||
187
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the vast majority of production deployments, you might encounter a dedicated AAA/RADIUS server solution for
authenticating users and devices, classifying them, and applying specific policies. Generally speaking this is also the
recommended approach, because a full-blown AAA/RADIUS server supports all the needed features to integrate with
external databases, private key infrastructures (PKI), monitor authentications, and the like. However, for some
situations, where an external AAA/RADIUS server may not be available, the WLC offers some local options to
authenticate users or devices, classify those devices, and enforce policies.
For 802.1X authentications, the WLC supports login-based EAP methods, such as LEAP, EAP-FAST, and PEAP, with
user accounts from its local database. Local EAP settings are available under SECURITY > Local EAP > Profiles.
You can create and manage the list of user accounts under SECURITY > AAA > Local Net Users.
On top of login-based EAP methods, the WLC supports EAP-TLS as a certificate-based authentication technique.
Login, or more precisely tunnel-based, authentication methods and EAP-TLS require a server certificate and, for EAP-
TLS, a root certification authority certificate to trust the clients’ certificates. Both the WLC’s server certificate and the
root CA certificate can be uploaded under COMMANDS > Download File, respectively with the options for Vendor
Device Certificate and Vendor CA Certificate under the File Type drop-down menu. To generate a WLC’s server
certificate for EAP-TLS, you can follow the same procedure as for the web authentication certificate, although the CN
should differ from the IP or the FQDN of the virtual interface in this case:
https://www.cisco.com/c/en/us/support/docs/wireless/4400-series-wireless-lan-controllers/109597-csr-chained-
certificates-wlc-00.html
The workflow to enable local EAP for an SSID consists in first creating a local EAP profile with the supported EAP
methods, and then in linking that profile to the WLAN, under its Security > AAA Servers tab. Before starting using it,
you should also make sure that the needed user accounts are created or that the right WLC’s certificates have been
uploaded.
189
||||||||||||||||||||
||||||||||||||||||||
The rules to match a client to a profile are the same as you could find in the profiling policies in Cisco ISE. Although the
WLC does not support modifying its local profiling policies, it supports importing new versions of them. Under
COMMANDS > Download File and through the Device Profile file type, you can import new versions of profiling
rules, which you could have previously exported from ISE, for example. To update the OUI database, you can follow
the same procedure by using the file type OUI Update instead.
As a further extension of local AAA features on the WLC, you can also use 802.1X/EAP methods and device profiles
as conditions to match and apply local policies to users or devices of a specific SSID.
You can create and modify local policies on the WLC under SECURITY > Local Policies, as shown in Figure 4-24. A
local policy is matched based on the role string, the EAP method (both through local EAP or when authenticating
through an external RADIUS server), or the device type from the local profiling. When a client matches a local policy,
different types of settings can be assigned to it. The most common ones are a VLAN, an ACL, and a QoS profile, but
you can also implement more advanced options, such as an AVC profile or an mDNS service.
190
Technet24
||||||||||||||||||||
||||||||||||||||||||
191
||||||||||||||||||||
||||||||||||||||||||
Access control lists and certificates are some more “classic” security options, which you can find extensively detailed in
the configuration guides. We will briefly go through some of their uses, while leaving all the other already available
information to the online guides.
ACLs on a WLC are historically Layer 3 or Layer 4 ACLs and you can configure them under SECURITY > Access
Control Lists. An ACL allows filtering based on IPs or subnets, both as source and destination, but also based on
protocols, ports, and DSCP values. You can also specify in which direction an ACL should apply; inbound or outbound.
Inbound means traffic coming in from the wireless clients, and outbound means traffic going out to the wireless clients.
You can statically apply ACLs to a dynamic interface or to a WLAN, or you can dynamically assign them through the
RADIUS vendor-specific attribute Airespace-ACL-Name. ACLs also serve as pre-web authentication ACLs, again
either statically configured under a WLAN for Local Web Authentication (LWA) or dynamically assigned via the
RADIUS attribute cisco-av-pair=url-redirect-acl=<ACL_NAME> for Central Web Authentication (CWA).
Under an ACL you can configure permit statements for fully qualified domain names (FQDN) too, as shown in Figure
4-25. These statements apply to clients in the WEBAUTH_REQD state, or any other state for web redirection, hence
only if the ACL is used as a pre-web authentication ACL.
Figure 4-25 Example of FQDN Filtering Options for a Pre-Web Authentication ACL
The screenshot shows the WLANs menu selected from the main menu tabs at the top. The Edit cisco page
displays five tabs from which Advanced tab is selected. The settings of the tab are as follows: Scan Defer
Policy option shows checkboxes ranging from 0 to 7 (4, 5, and 6 are selected) and Scan Defer Time (msecs)
field reading 100. A section titled Flexconnect shows the following options with a checkbox to enable the
options: FlexConnect Local Switching, FlexConnect Local Auth, Learn Client IP Address, Vlan based Central
Switching, Central DHCP Processing, Override DNS, NAT-PAT, and Central Assoc.
As of AireOS 8.4 you also have the option to configure FQDN ACLs for clients in the RUN state. These can be found
192
Technet24
||||||||||||||||||||
||||||||||||||||||||
Web authentication portal: This is the certificate presented when being redirected to the web portal hosted on the
virtual interface, and its common name should be the virtual interface’s IP or FQDN. In the same way as for the
web admin certificate, you can generate the CSR for the web authentication certificate through OpenSSL, or even
through the WLC’s command config certificate generate csr-webauth and its options. All the configuration
details are the same as in the aforementioned URL.
EAP certificate: This is the authentication server certificate for the WLC when using local EAP profiles. Under the
GUI, you can download such a certificate under COMMANDS > Download File by choosing Vendor Device
Certificate as a file type; this corresponds to the data type option eapdevcert when using the transfer download
command line. Although usually recommended for ease of use, the common name for the EAP device certificate
does not necessarily need to match the WLC’s management IP or FQDN, because during an EAP authentication a
client does not/cannot reach that IP/FQDN to verify it. Along with the EAP certificate for the WLC itself, you also
must download the certification authority’s certificate to trust clients’ certificates for EAP-TLS, for example. You
can follow the same procedure as for the device certificate, by choosing Vendor CA Certificate as a file type in the
GUI, or eapcacert as a data type via CLI.
On top of these main use cases, the WLC also supports the download of other types of certificates, such as the CA
server certificate for LSC certificates installation on APs, which we discussed in the previous sections.
FlexConnect Deployments
FlexConnect is a special mode in which you can set mostly any access points (there have been some restrictions on the
193
||||||||||||||||||||
||||||||||||||||||||
The FlexConnect mode doesn’t do or change anything per se (that is, if it’s the only thing you enable) apart from
adapting the AP state machine, behaviors, and timers to act properly considering there is a WAN link between it and the
WLC. Moving an AP to FlexConnect mode does not require a reboot and is close to instantaneous, but moving an AP
back to local mode requires a reboot.
The requirements for FlexConnect mode are the following: less than 100ms latency between AP and WLC (if only
doing data, up to 300ms can be tolerated), 128kbps of bandwidth per group of 8 APs, and at least an MTU of 500. The
AP itself is very delay tolerant, but the client does not necessarily realize that the AP needs to consult with a WLC
behind a WAN link, and issues may arise if latency is longer than 100ms because of the client growing impatient. There
are CAPWAP heartbeats every 30 seconds and if one is lost, five (one per second) are sent consecutively. If they fail,
the connectivity is declared lost, and the AP moves to standalone mode; therefore, there is some small tolerance to
packet drop but it shouldn’t be abused.
There are two traffic switching modes in FlexConnect: central and local switching. With a default WLAN configuration,
FlexConnect mode APs will centrally switch client traffic, which means that they will send all the client traffic in a
CAPWAP tunnel to the WLC. There is no change of behavior (from a traffic switching perspective) compared to a non-
FlexConnect AP (that is, local mode). However, if the WLAN has the check box for FlexConnect Local Switching, this
WLAN will be locally switched on all the APs that are in FlexConnect mode (local mode APs will still behave as they
always do). This means that the AP gives the client traffic directly to the connected switch without any encapsulation.
The AP still has a CAPWAP tunnel for control traffic: AP configuration, WLC statistics and monitoring, but also client
authentication. But as soon as the client is in RUN state (fully forwarding the client traffic), the AP converts the 802.11
frame to an 802.3 frame and sends it on its connected switch (much like autonomous IOS APs did). APs can support
several VLAN tags in such a mode and have some WLANs centrally switched while others will be locally switched on
the connected switch at the branch. Figure 4-26 illustrates the WLAN settings that will allow you to configure some
WLANs as locally switched while others will stay centrally switched:
194
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
The illustration shows two sections: Branch and Corporate Central. The Branch section shows a user
connected to CAPWAP (FlexConnect) via a wireless connection. This, in turn, is connected to a switch
(via dot1q) followed by a router for transmitting user data. An arrow representing local switched user data
from the router points to the branch servers and to the corporate central section. A double-headed arrow
representing local switched user data exists between CAPWAP and the router. The corporate central
section shows cisco prime infrastructure: A router is connected to a centralized WLAN controller for
196
Technet24
||||||||||||||||||||
||||||||||||||||||||
The illustration shows two sections: Branch and Corporate Central. The Branch section shows a existing
user and a new user connected to CAPWAP (FlexConnect) via a wireless connection. A cancel icon is
shown over the wireless connection between new user and CAPWAP. This, in turn, is connected to a
switch (via dot1q) followed by a router for transmitting user data. An arrow representing local switched
user data from the router points to the branch servers and to the corporate central section. A double-headed
arrow representing local switched user data exists between CAPWAP and the router. The corporate central
section shows cisco prime infrastructure: A router is connected to a centralized WLAN controller for
transmitting user data. The router of branch section and corporate central are connected via serial cable
with a cancel icon over it. A double-headed arrow representing 802.1x exists between AAA and centralized
WLAN controller with a cancel icon over it. A private network cloud is also shown. A double-headed
arrow representing CAPWAP control from CAPWAP points to corporate central with a cancel icon. An
arrow labeled OR points to the connection of routers and AAA and Centralized WLAN controller.
Authentication local/switching local: If you manually configure local authentication on top of local switching, the
AP is as resilient as it can be for this WLAN. Even if WLC connectivity is lost, the AP will continue to function
and fully operate on this WLAN. There are, however, some limitations with regard to authentication types that the
AP can handle (mainly regarding EAP authentications, while some other methods, like Open authentication or
WPA/WPA2-PSK, can be handled at the AP for new clients without any local authentication configuration but
when the AP is in standalone mode after losing connection with the WLC).
It is important to note that FlexConnect brings some limitations to certain features: sometimes only in local switching
mode, sometimes across the board. Take a look at the “FlexConnect Feature Matrix” online for a list of what is
supported in what mode.
197
||||||||||||||||||||
||||||||||||||||||||
The WLAN Advanced tab contains a few more FlexConnect specific features:
FlexConnect local switching: When enabled, this WLAN will be locally switched on all FlexConnect APs.
FlexConnect local auth: This enables FlexConnect APs to take care of the authentication as well locally. They will
fallback to local authentication in standalone mode. Note that you will have to enable local auth as well in the
FlexConnect group options to have the AP always using local authentication (even in connected mode).
Learn Client IP address: Because the DHCP traffic is switched at the remote office, the WLC doesn’t have the
opportunity to track the client IP address. If you enable this feature, the AP will send a copy of the DHCP packets
inside the CAPWAP tunnel for the WLC to learn the client IP address.
VLAN-based central switching: When enabled, this feature allows having some clients centrally switched and
other clients locally switched on the same WLAN on the same FlexConnect AP. With this feature disabled, you can
assign a dynamic VLAN in the AAA attributes after the client authentication, and if the VLAN exists on the AP,
the client will be switched locally on that VLAN. However, if the VLAN does not exist on the AP, the client is
unable to connect. With this feature enabled, if the AAA server returns a VLAN that does not exist on the AP, the
client will be centrally switched on the WLC with the interface that corresponds to that VLAN (if it exists; if that
VLAN is also not present on the WLC, then the WLAN default interface is chosen).
Central DHCP Processing: In some cases, you might want FlexConnect locally switched clients to still obtain
their IP from a central DHCP. A great configuration example is available online if you search for “FlexConnect
Central DHCP configuration example.”
NAT-PAT: If you enable Central DHCP Processing, but the subnet used by the dynamic interface on the WLC
does not exist on the remote office site, you must enable NAT-PAT for the AP to do NAT on the client traffic so
that the client can talk to the remote resources.
Central Assoc: In a FlexConnect local switching SSID, all the 802.11 functions are handled at the AP level.
However, if the AP responds with “association response” by itself (for latency reasons), it still sends the association
request to the WLC and checks the WLC answer as well. When the Central Assoc check box is enabled, the Flex
AP will not send the association response by itself and will wait on the WLC to handle it and answer the client with
the WLC answer only.
We have already talked about FlexConnect groups earlier in this chapter, but let’s focus on some features that are very
specific to FlexConnect and that we haven’t talked about yet. In the General tab of the FlexConnect group, you can
enable AP local authentication. This is the check box, which on top of the WLAN local auth enablement, will make the
FlexConnect AP do local auth on a permanent basis (not only when it is in standalone mode). It will then be able to do
PSK locally, or act as a dot1x authenticator and forward RADIUS authentications directly to a RADIUS server (which
means having each and every FlexConnect AP where local auth is turned on, configured as AAA clients on the
RADIUS server), or even do EAP authentication itself (acting as Local RADIUS Server) with a limited user database
size and limited EAP methods available. More details on that in the Local Authentication tab right next to the General
tab. In the Image Upgrade tab, you can enable the AP upgrade feature and designate Master APs in the group. This
means that in case of software upgrade (on the WLC), rather than downloading their new image from the WLC, which
is potentially behind a slow WAN link, the APs can download it from a master AP directly (which got its image first
from the WLC and will redistribute it then locally at the remote site). This needs to happen between AP models using
the same software image.
198
Technet24
||||||||||||||||||||
||||||||||||||||||||
OfficeExtend
OfficeExtend is similar to FlexConnect in some ways and is a kind of extension of it, but with differences. OfficeExtend
targets remote workers typically having a home (or office-provided) router with their own ISP connection and looking
to connect a Cisco AP behind all that so that it connects to the company HQ WLC, as illustrated in Figure 4-29.
OfficeExtend therefore expects NAT to happen between the AP and the WLC, and OfficeExtend by default (and this is
not configurable) will enable DTLS data encryption on traffic tunneled to the WLC.
199
||||||||||||||||||||
||||||||||||||||||||
The "Office-Extend" topology shows a network at the center that is connected to Home network on the left and
Office network on the right. The "Corporate SSID (a mobile and a laptop)" is connected to an "OfficeExtend
Access point" through the "Wireless Connectivity." The access point is further connected to a router that is in
turn connected to a "DSL/Cable modem" and is connected to the network. In the office network, the outer
network is connected to a router that is connected to a Firewall and in turn, it is connected to a
"Controller/CC."
Setting an AP to OfficeExtend mode happens in the FlexConnect tab of the AP settings (the AP must be in FlexConnect
mode already). You can then have a few options, like Enable Least Latency Controller, which will allow the AP to join
the WLC with the lowest latency. Table 4-1 details some of the more common FlexConnect-related show commands.
Table 4-1 FlexConnect-Related show Commands
Command Purpose
IOS-AP# show capwap reap Displays all serviced WLANs on each radio with their VLAN and profile
assoc configuration
IOS-AP# show capwap reap Shows saved FlexConnect configuration on the AP side
saved
Shows the AP config in the style of an autonomous IOS config (allows you to verify
IOS-AP# show run
VLAN assignments and access list)
IOS-AP# show ip access-list Shows the access lists loaded on the AP
Wave2AP# show Flexconnect Shows the FlexConnect configuration and status of each WLAN on the AP
wlan
Wave2AP# show Flexconnect Shows the VLAN and ACL mapping configuration on the AP
vlan-acl
WLC> show ap config Displays the current configuration of the given AP
general <Apname>
Another specificity of the OfficeExtend mode AP is that clients at the remote site will be able to reach out to the AP IP
address (typically a local LAN IP) and get a web UI for the AP. This web UI shows the AP console logs (for onsite
troubleshooting), allows you to set a WLC IP address (for easy provisioning), to monitor some metrics on the AP, but
also to configure a personal SSID. This personal SSID will be available only on that AP and therefore is not seen on the
WLC anywhere. That SSID will be locally switched at the remote site and is offered for convenience; it will not give
access to corporate resources. In the Wireless > Global Configuration Settings page, you have an OfficeExtend (in the
OEAP config section) specific option to prevent this local access to the AP if you don’t want remote site users to access
it. There are certain AP models that will come in OfficeExtend mode and are sometimes locked to that mode
(600OEAP, 700OEAP, 1810-OEAP, or 1815T); this gives the ability to order the APs, ship them to an employee’s
200
Technet24
||||||||||||||||||||
||||||||||||||||||||
In a Cisco network, mesh access points can have either of two roles:
Root access points (RAP) are configured to connect to the WLC using only their Ethernet connection. When
deployed in the field, RAPs are used by the other mesh APs as relays to reach the wire, and through the wire, the
WLC.
Mesh access points (MAP) are configured to use their Ethernet connection to reach the WLC. When such an
attempt fails, the MAP uses its radio interface (5 GHz unless configured specifically to use the 2.4 GHz radio) to
find a RAP (directly, or through another MAP) and reach the WLC that way.
Mesh Topologies
A consequence of this role structure is that Cisco mesh networks form trees, where the RAP is the trunk or the root, and
the MAPs branches. All APs in a tree are on the same 5 GHz channel (called the backhaul), unless APs have more than
one 5 GHz radio (in which case the uplink and downlink radio may be on different channel), as shown in Figure 4-30.
In the Mesh Network topology, "Layer 3 switch" at the center is connected to a "Dual-band access point" that
is further connected to three "Dual-band access point" through the channel 149 and they are further connected
to five dual-band access points and in turn, they are connected to five laptops. The "Layer 3 switch" points to
an internal, Apps, and Internet at the top. In the "Dual 5GHz Radio Mesh Network" an "Layer 3 switch" is
connected to an Internal, Apps, and Internet at the top and a dual-band access point at the bottom that is
201
||||||||||||||||||||
||||||||||||||||||||
When a MAP boots, it first tries to join the WLC using its Ethernet interface (if it is detected as connected). If this
discovery fails, the MAP turns to its 5 GHz radio and scans all channels to discover a MAP or a RAP.
Each mesh AP connected to the WLC (as a RAP, or as a MAP through other APs) sends a status message on its 5 GHz
channel every 500 ms. This message informs possible other MAPs about the link availability to the WLC, along with a
value (the adjusted ease detailed later in this section) that expresses the quality of that link to the WLC. If more than
one AP is detected offering such a link, the MAP will use the Adaptive Wireless Path Protocol (AWPP), a Cisco
proprietary algorithm, to determine which AP offers the best path to the wire. The metric used for this protocol is a
combination of hop counts and SNR between APs on the path. The result of this metric computation for each hop is
called the ease value. A larger ease value typically reflects a better link. When multiple hops are combined, the adjusted
ease value reflects the link for the entire path (through all the hops needed to reach the wire). The highest adjusted ease
value represents the path with the best signal on each hop, for the least number of hops overall. In AireOS code releases
8.3 and later, the ease computation also includes link load values, and timers (frame travel time).
This discovery is efficient. As a CCIE, you should know how to force an AP through a specific path. However, in real
life, the adjusted ease represents the best path. Forcing your AP through another path should be done only if you have
good reasons to do so; a path does not become “acceptable” (from an RF standpoint) just because you force an AP to
use it.
After a MAP has scanned and discovered multiple possible paths, it will choose the link offering the best adjusted ease.
Once the MAP has joined the WLC, that chosen path receives an additional 20% “active path bonus” that is added to
its computed ease. This mechanism prevents jumpiness, where an AP jumps back and forth between two parents of
approximately the same ease value as the RF conditions change.
In a higher density network, there may be more than one mesh network in place in the same RF space. To resolve this
issue, you can configure your APs, after they have joined a WLC, with a group value called the Bridge Group Name
(BGN). The default value is Default.
202
Technet24
||||||||||||||||||||
||||||||||||||||||||
Configuring mesh networks is straightforward because this configuration always consist of the same steps. Advanced
configurations may contain more possibilities, so make sure you master the basics before attempting nondefaults.
Your AP may already be in mesh (called Bridge) mode—you can order APs already set in that mode. When using APs
in standard mode, you need to switch them to mesh mode. This mode is called on the WLC Bridge mode (we’ll use this
correct terminology from now on), as shown in Figure 4-31. It is performed from Wireless > Select AP > General (CLI
config ap mode bridge <ap>). Setting the AP to Bridge mode requires that the AP 5 GHz radio channel and power be
set to Custom (CLI config 802.11a channel ap <ap> <any channel> and config 802.11a txPower ap <ap> 1).
In the Cisco window, "Wireless" tab is selected that displays a list in the navigation pane where "All APs" is
selected. Under All APs, "detailed for AP7cad.74ff.36d2" window is displayed. In the content pane "general"
tab is selected that displays the following sections: General, versions, language venue name, IP Config, Time
statics, hardware reset, and set to factory defaults. The "Admin Status" mode is set to enable. The "AP mode"
shows a list where "Bridge" is selected.
To prevent someone from attempting to have their AP join your WLC, you must authorize mesh APs on WLCs. This
authorization is by default a simple MAC address filter. From the screen shown in Figure 4-32, copy the AP MAC
203
||||||||||||||||||||
||||||||||||||||||||
204
Technet24
||||||||||||||||||||
||||||||||||||||||||
205
||||||||||||||||||||
||||||||||||||||||||
Beyond the options relative to the AP itself, you may be asked to configure general options for the mesh network itself
(in the CLI, starting with config mesh keyword). Many of these options are in the Wireless > Mesh menu, as displayed
in Figure 4-34:
Technet24
||||||||||||||||||||
||||||||||||||||||||
Global Public Safety: This feature is useful in the FCC regulatory domains to activate the 4.9 GHz safety bands.
Outdoor Ext. UNII B Domain Channels: The FCC regulatory domain allows new channels for outdoor usage
(UNII 1 channels 36, 40, 44, 48, and UNII 2 extended channel 144). UNII1 was allowed only for indoor use in the
prior rules (called A domain). The FCC allows UNII1 outdoor, and a new UNII2e channel with the B domain rules.
You can enable the B rules by checking this Outdoor Ext. UNII B Domain Channels option.
Convergence mode: This option is valid on AireOS code 8.3 and later. Each AP keeps track of its neighbors. When
a parent is lost, detecting the loss takes time (nonresponse to a certain number of keepalive messages). Then,
scanning all channels for a new parent also takes time. To expedite the process, in case of a parent loss, you can
choose a different convergence set of timers. With the standard mode, an AP takes 21 seconds to detect a parent
loss, then scans all channels to find a better parent. With the Fast mode, the AP waits only 7 seconds to decide that
207
||||||||||||||||||||
||||||||||||||||||||
Authorizing your mesh APs to join the WLC is a key component of the deployment task. During the discovery phase, a
MAP will scan channels, discover the AP with the best Ease value in its Neighbor Update messages, and then
authenticate to the RAP. This phase is used to ensure that the backhaul link is encrypted. This authentication can be
done using EAP-FAST, leveraging the AP’s certificates (default). However, you may want to use PSK instead. This is
useful if your AP is an old model with LSC certificates, or an expired certificate, or if you are unable to provide a
proper clock synchronization to your system. You can change the authentication to PSK from the Wireless > Mesh >
Security section (CLI config mesh security psk). You then have to set the PSK. You should be aware that your APs
first must join the WLC so that they can be provisioned with the PSK. They will then use PSK on their next join
attempt. If new APs join a PSK-based system, authentication will fail, as the new AP does not know the PSK. To
prevent this issue, choose the Default PSK option, allowing the new AP to use a factory-built value for the PSK and join
successfully, even if the PSK you configured on the WLC is unknown to the new AP. In that case, you may also want
to choose PSK provisioning, to push the new PSK value to the joining AP. Using these two options allows any Cisco AP
to join your WLC. You would enable them only when new APs are expected to join the mesh.
One confusing aspect of this authentication to the RAP is that the goal is to encrypt the mesh backhaul. However, the
RAP is not an authentication server. During the authentication phase, the RAP relays the query to the WLC, and the
WLC is the entity performing the authentication validation. However, at this point, the WLC is not authenticating the
MAP directly; it is merely validating the requests from the RAP so as to enable backhaul link encryption. The MAP has
not joined the WLC yet.
After encryption to the RAP is achieved, the MAP uses the backhaul link to send CAPWAP messages to the WLC. At
this point, the WLC needs to authenticate the MAP. The authentication can use a MAC address filter configured on the
WLC, as described earlier in this section. In some cases, it may not be practical to use such a MAC filter. A typical
example is mining operations where APs are moved between sites, and a single AP may end up on any number of local
controllers. Entering all the MAC addresses of all possible APs on all WLCs is inefficient in this context. In this
environment, you can set the MAP to authenticate using only its certificate, by checking the LSC only MAP
Authentication (CLI config mesh security lsc-only-auth). The WLC will then validate the AP certificate but ignore the
MAC address filter.
Note
208
Technet24
||||||||||||||||||||
||||||||||||||||||||
Local bridging has long been a salient feature of mesh networks, allowing devices connected to your MAP to send
traffic through the backhaul. The original use case was about street cameras, but many deployments ended up
connecting switches and entire networks to these MAPs. The requirements of local bridging became so close to
FlexConnect local switching that both modes were merged for Mesh networks in WLC code AireOS 8.0. The result is
that both modes are often confused.
Without Flex configuration (that is, when your APs are configured in regular Bridging mode), you can enable Local
Bridging on the AP. For each AP on the link, enable Ethernet Bridging in the AP Mesh configuration tab. This must be
done on all APs on the link (if MAP2 uses MAP1 to reach RAP1 and you need to relay traffic from a camera connected
to MAP2 Ethernet interface, you need to enable Ethernet bridging on MAP2, MAP1, and RAP1). This function is
disabled by default to prevent anyone from connecting something to your mesh APs and sending traffic over the
backhaul.
If your APs connect to switches on a trunk port, you also need to enable VLAN support for these APs. Check the
VLAN support option and click Apply. When you come back to that same page, you can decide the native VLAN
value, and also click the Ethernet interface at the bottom of the screen to configure the VLANs you need supported
across the AP interfaces (radio and Ethernet). This configuration is not always needed on the MAP if it connects to an
access port; however, it is often needed on the RAP. You should also keep in mind that enabling Local Bridging does
exactly what the name implies: when traffic coming from the backhaul reaches the RAP, it is bridged locally (that is, not
forwarded to the WLC).
In addition to this regular local Bridging function, you can enable the AP to operate in Flex+Bridge mode. The main
features of this mode are represented in Figure 4-35.
209
||||||||||||||||||||
||||||||||||||||||||
210
Technet24
||||||||||||||||||||
||||||||||||||||||||
Proper mesh operations can be verified from the WLC UI, from the Neighbor Information option, found in the blue
chevron of an AP line in Wireless > All APs. The neighbor information is shown in Figure 4-36. You can get the same
information from the CLI (using show mesh family of commands).
In the Mesh verification, two screenshots overlap the first window. A cisco window is shown where the
"Wireless" tab is selected that displays a list in the navigation pane where "FlexConnect Groups" is selected.
The column headers in the content pane read "AP Mode, Certificate type, OEAP, Primary SW version, Backup
SW version, AP sub-mode, Download status, Upgrade Role (Master/slave), mDNS status, Universal AP,
Hyperlocation, and Fabric status. The drop-down in the second row of Fabric status shows a small list where
"Neighbor" is selected that displays the details of "Neighbor info" in a Cisco window. In the first overlapping
window, "Wireless" tab is selected that displays a list in the navigation pane where "RAP1" is selected under
"All Apps." The column headers of the "Neighbor Info" are "Mesh type, AP name/Mac, Neighbor backhaul
MAC, Source Backhaul NAC, Slot ID, Neighbor channel, and Source Channel." In the first row, a drop-down is
shown at the end that displays a list where "details" is selected. The second overlapping Cisco Window where
the "Wireless" tab is selected that displays a list in the navigation pane where "All APs" is selected. The "Link
details" of the RAP1 are listed as follows: Neighbor AP name/MAC, Neighbor base radio MAC, Neighbor
Type, channel, Backhaul Data rate, Link SNR, and Time of last hello.
From these pages, you should be able to verify neighbor relationships, parent-children links along with transmitted
frames, and signal quality. In most cases where issues affect APs that have already joined, these pages will help you
determine why an AP did not choose the path you designed, or why APs form a different relationship from the one you
expected.
In real life, multiple issues may affect your mesh network. In the lab, beyond link and RF problems, the most common
issue for mesh is an AP failing to join. You should be aware that mesh convergence takes time. It is not uncommon for
211
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Without getting back too much into the RF Layer 1 theory again, two main things can be tweaked to optimize a wireless
deployment: transmit power and channels used. Of course, the most important is the physical placement of APs and
antennas and overall design, but that is not part of the CCIE wireless lab exam. After a network is up, it mostly boils
down to changing the power and the channel of APs to achieve the best efficiency possible depending on your
requirements and current deployment.
The 2.4 GHz band is typically straightforward, despite the availability of 11 (or 13 or 14, depending on country)
channels, you can only use 3 because we definitely want to use non-overlapping channels to avoid adjacent-channel
interference. There is a global agreement that channels 1, 6, and 11 are the best to use. (Although some people try a 4-
channel plan with 1, 5, 9, and 13, this is not recommended for all deployments and is anyway restricted to countries
where more than 11 channels are available.) The 5 GHz band doesn’t have such restriction, and you can basically pick
any channel you like because they do not overlap. However, 802.11n brought 40 MHz channels and 802.11ac brought
80 MHz channels, which adds a layer of complexity to the channel plan. 40 MHz channels include a “primary 20 MHz
channel,” which means that if an AP declares to be on (36, 40), all management and control frames are sent at 20 MHz
width on channel 36, for example, and clients are allowed to send 40 MHz wide data frames on both 36 and 40. So 36
serves as primary channel for all the nondata frames as well as clients who might not support 40 MHz. The concept is
the same with 80 MHz, where there is a primary 20 MHz channel (for all nondata frames) and a primary 40 MHz
213
||||||||||||||||||||
||||||||||||||||||||
Figure 4-37 Example of Channel Width with Primary and Secondary Channels
The sample shows eight channels where the first two channels represent Secondary 40, the third channel
represents the Primary, and the remaining channels represent Secondary 80. The width of the channels are as
follows: Primary and the second secondary channel: 40MHz; First secondary40, primary, and second
secondary4o channel: 80MHz and all other channels 160MHz or 80+80MHz.
This means that the primary 20 MHz must not necessarily be the first channel in ascending order, which in turn means
that you could imagine an AP on “(40,36)”, which would have its primary channel on 40 and another AP close by on
“(36,40)”, which would have its primary channel on 36. Both would have to share medium when sending 40 MHz data
frames but could send 20 MHz management frames at the same time because they would then be on different channels.
This is not optimal (it’s best to have them fully on separate channels) but this is something that can be done. Secondary
channels have different Clear Channel Assessment (CCA), depending on the client standard (802.11n or 802.11ac),
which changes the received signal strength value at which a station can consider the medium to be free to transmit. All
of this makes it harder and harder to fully design a channel plan statically in a mixed real-life environment.
Because the 2.4 GHz wavelength tends to cover a greater distance for an equal modulation, and because designs are
typically made with 5 GHz in mind, newer deployments typically have too many 2.4 GHz radios and with only three
available non-overlapping channels (that are possibly sharing the air with Bluetooth, microwaves, or any other IoT kind
of device), it has become a “best effort” band. There are still single band wireless clients, so it might still be desirable to
provide 2.4 GHz coverage for those, at least in specific areas, but no one talks about high density with 2.4 GHz because
this is impossible due to the lack of channels. The 2.4 GHz band is still very useful for RFID and tags location tracking
as well as other IoT usage, though, but 5 GHz will take most of the requirement with regard to video and audio
streaming, real-time applications, and bandwidth-intensive applications.
The 5 GHz band still has a few tricks to clarify, though. Only channels 36 to 48 are strictly non-DFS channels in every
country. Most (and often all) of the others are DFS regulated channels (in most countries, with exceptions), which
means that an AP arriving on that channel will have to wait one minute to make sure there is no radar on that channel; it
can then transmit beacons. Clients don’t need to do this check if there is an access point already beaconing on that DFS
channel. The DFS regulation enforces 10 minutes wait time on channel 120 to 128 before an AP can beacon, rendering
these three channels very impractical, and many APs do not support them for this reason. Support on the client side also
differs greatly; more and more clients support more and more of the UNII-2 extended channels, but it’s unrealistic to
hope that all your clients will support all the channels that your AP might support. Over the years, more channels
214
Technet24
||||||||||||||||||||
||||||||||||||||||||
Static Assignment
The WLC allows you to configure each radio of each AP in a static manner or to leave it managed by the RRM
algorithm (as illustrated in Figure 4-38). When the radio has static assignments, the little asterisk next to it disappears,
meaning that the radio assignment is not managed by RRM anymore. The channel, channel width (20, 40, 80, 160), and
transmit power can be assigned manually (as shown in Figure 4-39).
Figure 4-38 Asterisk Means the Channel or Tx Power Is Set Globally by RRM
In the Cisco window, "Wireless" tab is selected that displays a list in the navigation pane where "802.11a/n/ac"
is selected under Radios. In the content pane, the column header reads: AP name, radio slot, Base radio MAC,
Sub-band, Admin status, operational status, channel, CleanAir/SI admin status, CleanAir/SI Operation Status,
Mesh Radio Role, Radio Role, and Power level.
215
||||||||||||||||||||
||||||||||||||||||||
In the RF Channel assignment, the "Current channel" is set to 100 and the "Channel width" is set to 20MHz
(from a spin box). A radio button is selected for "Global" under the "Assignment method." The "Radar
Information section" shows the column headers "Channel and Last Header (Seconds)." Under "Tx (Transmit)
power level assignment," the "Current transmit power level" is set to 1 and the "Global" radio button is selected
for "Assignment method." The "Performance Profile" shows the "Performance Profile" button.
216
Technet24
||||||||||||||||||||
||||||||||||||||||||
The RRM algorithm is actually several separate and mostly unrelated algorithms, each taking care of one specific
functionality:
Transmit Power Control (TPC) is in charge of decreasing the transmit power of specific AP radios in case there are
several APs very close to each other (which would then interfere with each other).
Coverage Hole Detection algorithm (CHD or CHDM) is in charge of increasing the power of radios (so the
complete opposite of TPC) if there are several clients that stick to that radio at a poor signal strength.
Dynamic Channel Assignment (DCA) is in charge of choosing the best channel for each AP radio, taking all
surrounding radio channels as well to come up with the most optimal channel plan.
Flexible Radio Assignment (FRA) is a newer addition to RRM and takes care of APs with flexible XOR radios
(2800, 3800, 4800 at the time of this writing). It will decide whether there are too many 2.4 GHz radios providing
client coverage and either turn some into monitoring radios or 5 GHz clients serving.
But before diving into these algorithms, it is important to understand based on what metrics all those algorithms make
their decisions. APs are involved in some data collections activities regardless of the algorithms that are enabled or
configured, and it’s with these data that the RRM algorithms will make their decisions.
Off-Channel Scanning
In a nutshell, APs will go off their client-serving channel to scan very briefly other channels and will also send a
neighboring packet to help neighboring APs discover and learn about them. In the Wireless> 802.11a/b > RRM page
(shown in Figure 4-40), we can set the channel list for monitoring channels (for noise, interference, rogue, and
CleanAir).
If set to Country Channels, the APs will scan and send discovery neighboring packets on all the channels supported
officially in the country (regardless of whether you restricted the channel list for DCA).
If set to All Channels, the APs will scan on all the channels that their hardware supports. This includes channels not
supported in the configured country; however, the AP will only passively scan (that is, listen) there and cannot
transmit on those channels (to avoid violating laws).
If set to DCA Channel List, the AP will only scan and send discovery neighboring packets on channels configured
in the DCA list (that is, the list of channels we configured the AP to pick from). This typically would restrict the AP
scanning channels 1, 6, and 11 on 2.4 GHz because it’s common to have only those three enabled for the AP to pick
from. The result is that your APs will not detect any rogue that would be present on channels 3 or 9, for example.
217
||||||||||||||||||||
||||||||||||||||||||
In the settings page, "Wireless" tab is selected that displays a list in the navigation pane where, 802.11a is
selected under the access point. RRM is selected under the 802.11a that displays the general settings in the
content pane. The "Profile Threshold for traps" section shows the fields "Interface, clients, noise, and
utilization." The "Noise/Interface/Rogue/CleanAir" of the monitoring channels section shows the "Channel
list" that is set to "Country Channels (selected from a spin box)" and are section is highlighted. The
"Monitor Intervals (60 to 3600 seconds)" section shows the fields "Channel scan interval, neighbor packet
frequency, and Neighbor timeout factor (5 to 6)" and is shown inside a box. The "Factory default" shows
the "Se to factory default" button.
The same page allows you to set the timers for those scanning activities in the Monitor Intervals section. The Channel
Scan Interval field refers to the passive dwell activity. We already hinted a bit in the previous paragraph, but this
defines in which interval the AP must complete its passive scanning of all the configured channels (DCA, country, or all
channels). The radio will spend 50ms on that channel to passively listen for rogues, collect noise, and interference
metrics. This means that for a bit more than 50ms (because the radio must change channel and this takes a few ms) the
AP is outside of its channel (unavailable) without any means to warn clients about it. This time is usually small enough
for clients to try to retransmit their frames and not go crazy about the AP not responding anymore. To give two
examples, if we configured APs to scan the DCA channel list on 2.4 GHz, which would mean channels 1, 6, and 11,
then the AP has 180 seconds (because the monitoring interval is set to 180 seconds by default) to scan those three
channels. This implies that the AP will leave its channel every 60 seconds to scan another channel. If on 5 GHz, there
are 22 channels to scan in most countries, which means that the AP will scan another channel every 8.18 seconds in
order to be done within 180 seconds.
218
Technet24
||||||||||||||||||||
||||||||||||||||||||
RF Grouping
The NDP packets allow APs to hear each other over the air and identify other APs channel and transmit power settings,
but there must be some kind of grouping. It is not because two APs are Cisco models and hear each other that they
necessarily belong to the same deployment.
The RF group settings in the general controller settings allow for some administrative grouping: your APs will not try to
discuss with your neighbor company’s APs. You can decide whether to configure the same RF group on the various
WLCs you own, depending on whether you want APs from each WLC to take others into consideration. Inside each RF
group, there is also a concept of RF neighborhood. Indeed, there is little point for APs that are in separate buildings and
incapable of hearing each other to work together on a channel plan. An RF neighborhood determines a group of APs
that hear each other at −80dBm at least (they don’t necessarily need to hear each of the APs in the RF neighborhood,
but there should always be a way to relate all APs in the neighborhood through other neighbor APs belonging to the
group). This allows for an algorithm to run on smaller groups of APs that should care about each other, as shown on
Figure 4-41.
219
||||||||||||||||||||
||||||||||||||||||||
The RF neighborhood shows three figures. The "RF Group Bob" is connected to four "Lightweight double radio
access point" labeled "RF Neighborhood-1, RF Neighborhood-2, RF Neighborhood-3, and RF Neighborhood-
4." The signal strength between RF Neighborhood-1 and RF Neighborhood-4 is "less than negative 85 dBm." In
the second figure, the "RF group Bob" points to four "Lightweight double radio access point (two at the top and
two at the bottom) labeled "RF Neighborhood-1 and RF Neighborhood-2." The signal strength between RF
Neighborhood-1 is "greater than 80 dBm" and in the Neighborhood-2 is "greater than negative 80 dBm." The
signal strength between RF Neighborhood-1 and RF Neighborhood-2 is "lesser than negative 85 dBm." The
third figure shows "RF Neighborhood-1" consisting of an LWAPP that points to three "RF Group Bob." The
first Bob points to an LWAPP of the "RF Neighborhood-2" with signal strength "lesser than negative 85 dBm."
The second bob points to an LWAPP of "RF Neighborhood-2" with signal strength "greater than 80 dBm" and
to an LWAPP in the "RF Neighborhood-3." The third Bob points to another LWAPP of the "RF
Neighborhood-3" with signal strength "greater than 80 dBm."
Each RF group (which can span, or not, through multiple WLCs) must elect an RF group leader, which will be the WLC
responsible for the RF configuration, running the RRM algorithms, and collecting and storing the RF data and metrics.
There is an RF group leader per frequency band. It can be the same WLC, but not necessarily (some APs can hear each
other on 2.4 GHz but not on 5 GHz, so even the RF neighborhoods might not be the same). The RF leader is elected
based on a combination of the WLC model (the higher the model/capacity, the higher the priority) and the IP address.
The first condition for this to happen is that APs of different WLCs must hear each other over the air; then the WLCs
must be reachable via the wired network (UDP 12134->12124).
It is critical to understand that the RF leader will make the RF decisions; therefore, it is on the RF leader that the
settings will definitely matter. The RF grouping page, illustrated in Figure 4-42, lets you know who the RF leader for
each band is and how many APs are part of it, and lets you override the RF leader selection manually if desired.
220
Technet24
||||||||||||||||||||
||||||||||||||||||||
2800, 3800, and 4800 APs have a flexible XOR “slot 0” radio. It starts as a classical 2.4 GHz radio but can switch to 5
GHz or monitor both bands. Flexible radio assignment (FRA) first measures the coverage overlap factor (COF); that is,
the amount of superfluous 2.4 GHz radios that could be turned off without impacting coverage. It then manages the
radio roles of those APs with high COF, to either switch them to 5 GHz client serving or full dual-band monitoring.
Finally, it also takes care of the load balancing of clients between the two 5 GHz radios in a micro/macro cell scenario.
FRA runs with the same RRM metrics (mostly NDP packets) as other algorithms, and it takes all previous (non-XOR)
AP models into account to determine the 2.4 GHz coverage overlap factor. However, for now only the 2800/3800/4800
AP radios can be marked as superfluous and their role changed. The COF is the percentage of the analyzed cell that is
covered at −67dBm by other existing radios in service. So, if the COF of an AP is 100%, it means its 2.4 GHz radio can
be disabled without any loss of coverage (in fact, it will even lower same-channel interference and will improve your
airtime availability). The FRA page (illustrated in Figure 4-43) allows you to configure the COF threshold. At Low, it
will mark as redundant radios with a 100% COF; at Medium, it will mark as redundant radios with a 95% COF, and it
will be 90% for the High setting.
221
||||||||||||||||||||
||||||||||||||||||||
In the Cisco window, "Wireless" tab is selected that displays a list in the navigation pane where "Advanced"
menu is selected that displays the "Flexible Radio Assignment Configuration" in the content pane. Under
"Flexible Radio Assignment" in the content pane "Enable" radio button is selected. The "Sensitivity" fields
display a list where "low" is selected.
When a radio is redundant, FRA will try to make it a 5 GHz client serving radio unless DCA determines there are
already too many 5 GHz channels used. If DCA considers there is already enough 5 GHz coverage, it will switch the
radio to dual-band monitoring. It is interesting to note that when a radio was switched to 5 GHz client serving, it does
not participate anymore in COF calculation (it does not scan or send NDP packets on the 2.4 GHz band anymore), so
this role change cannot happen back and forth—once it moves to 5 GHz it does not come back. This is improved in 8.5
or later software, with a threshold determining at how many 2.4 GHz clients we consider we need a radio back in the
2.4 GHz. The AP settings page will allow you to select the automatic FRA or manual assignment as shown in Figure 4-
44.
222
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the AP settings page, the "Radio Role Assignment" shows radio buttons where "Manual and Client Serving"
is selected with the band that is set to "2.4Ghz (selected from a spin box)." The "RF Channel Assignment"
section shows the fields "Current Channel, Channel width, and Assignment method" where the "Global" radio
button is selected under the Assignment Method. The "Transmit Power Level Assignment" shows the fields
"Current Transmission Power Level and the Assignment Method" where the "Global" radio button is selected
under the Assignment Method.
Out of the box (that is, without a DART connector), the 2800 and 3800 APs can have only one set of dual-band
antennas (internal or external). This presents some limits to what is achievable: that is, set two radios on the same
223
||||||||||||||||||||
||||||||||||||||||||
Command Purpose
WLC> show advanced FRA Displays all the FRA settings
WLC> show advanced client-steering Shows all the macro/micro cell client-steering settings
WLC> config advanced fra revert all auto Reverts all APs to auto FRA configuration
WLC> config advanced fra enable Enables FRA globally
Dynamic channel assignment (DCA) will adjust the channels of APs in an RF group to optimize performance. It uses an
RSSI-based metric, but its calculation function is not publicly disclosed. A subcomponent of DCA is Dynamic
Bandwidth Selection (DBS), which can select the best bandwidth (20, 40, 80, 160) for each AP if the bandwidth setting
is set to Best, as illustrated in Figure 4-45.
224
Technet24
||||||||||||||||||||
||||||||||||||||||||
Persistent non-Wi-Fi interference: This also depicts interferers detected by CleanAir but only targets persistent
ones; that is, interferers that may not be present at any given time but were identified to be recurring enough to
cause a problem.
The same page also allows you to enable which channels DCA will pick from to assign to the APs. The algorithm will
run when set to Automatic; you can then set an interval and anchor time. It will run every <interval> minutes starting
from the anchor time. You can, for example, make it run every 6 hours starting from midnight (which would be the
same as setting it anchored at 6 a.m. or noon; it will run at midnight, 6 a.m., noon, and 6 p.m.). If set to Freeze, the
algorithm will not update channels anymore unless you click the update button next to it, but the NDP packets and off-
channel scanning will continue to happen (to collect metrics). If set to Off, it will not run, and metrics collection
activities will stop. You can see who the RF leader is, when the algorithm last ran, and set the sensitivity of the
algorithm in dB (the calculated nondisclosed RSSI-based metric). If you chose a channel width, that same width will be
used on all APs, but if set to Best, the width can be different on all APs.
When a WLC reboots, even if it is not the RF leader, the DCA algorithm will switch to startup mode in the RF group. In
startup mode, the DCA algorithm runs every 10 minutes for 100 minutes, regardless of what the configuration is. When
an AP reboots, it starts using its last saved channel setting, or if it’s a new AP it will start on the first available channel
(1 and 36).
225
||||||||||||||||||||
||||||||||||||||||||
The coverage hole function is the only one to run on every WLC (regardless of RF leader). This is because it does not
need to take many factors into account: The idea is that if several clients stick to one AP at a low signal strength, and
this AP is not already at the maximum power, we should then increase its power level. A precoverage hole event
happens if a single client stays for 5 seconds under the configured RSSI at the AP level. However, the precoverage hole
event is only for tracking purposes, and only an SNMP trap is sent. If the configured number of clients stay under this
threshold RSSI for more than 90 seconds, an actual coverage hole happens and actions are taken.
The default values are that you need at least three clients (the Min Failed Client Count Per AP setting) and they must
represent 25% of the client count of the AP (coverage exception level per AP) for a coverage hole to be declared. This
means that on default settings, the AP will only declare a coverage hole if it has, say, 12 clients, out of which 3 or more
are under the RSSI threshold for more than 90 seconds. This threshold is configurable but is −80dBm by default for data
and −75dBm for voice. Note that these RSSI settings are also used for optimized roaming features as explained later in
this chapter.
Coverage hole can be enabled on a per-WLAN basis. However, it is the detection that is enabled or not for a given
WLAN; the mitigation (that is, increasing AP power level by one) will affect all WLANs. The purpose is, for example,
to disable coverage hole detection on a given SSID (like the guest SSID) where we know we will have poor or sticky
clients, and we do not want those to trigger a coverage hole event.
CleanAir
CleanAir is a hardware spectrum analyzer chipset built in to the APs and present on all the 2000 and 3000 series of APs
as well as on high-end outdoors (such as 1570 or 1560). The CleanAir chip has a resolution of 78 KHz, which is much
less than what any Wi-Fi chipset can come down to. This allows the AP to have the capacity to identify non-Wi-Fi
signals. For non-CleanAir APs, any nondecodable signal is either non-Wi-Fi noise or even possibly a Wi-Fi signal that
was in too bad a condition (low SNR) to be decoded. CleanAir can identify the signal and figure out whether it’s a
microwave oven, a Bluetooth transmitter, and so on. On top of this device identification, it can also precisely analyze
the influence level and not rely only on the interferer RSSI. For example, it can calculate the duty cycle (the percentage
of air time used by this interferer) and therefore really differentiate important interferers from the ones you could live
with. In the Wireless > 802.11a(or b) > CleanAir page (as shown in Figure 4-46), you will have a few configuration
items.
226
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the Cisco window, "Wireless" tab is selected that displays a list in the navigation pane where the "Access
point: 802.11a" is selected. The 802.11a displays the fields of the CleanAir in the content pane. The
"CleanAir/Spectrum Intelligence Parameters" section shows the fields "CleanAir, Spectrum Intelligence, Report
Interface, and Persistent Device Propagation" where "Enable" checkbox for Report Interface is selected. The
"Trap Configurations" section shows the fields "Enable AQI trap, AQI Alarm threshold, enable trap, threshold
for unclassified category trap, and enable Interface for security alarm" where "Enabled" checkboxes are
selected for "Enabled AQI and Enable Interface for security alarm."
The CleanAir box enables CleanAir globally for that band. There is close to no impact when enabling CleanAir. You
can then enable the reporting of interferers as well as persistent device propagation, which will make the CleanAir APs
tell the non-CleanAir APs of the same WLC about persistent interferer so that they apply a bias in their DCA and try to
avoid those persistent devices.
Below, you can choose which interferer type to detect or ignore. Be aware that BLE beacon detection does cause some
packet loss on 2.4 GHz. All the other types have no impact on performance. CleanAir is a separate chipset from the Wi-
Fi radio (so no impact there) but it still has to use the same antennas as the Wi-Fi chipset and therefore can listen to the
medium only when the AP is not transmitting. This means that CleanAir is active only for the current channel on a
client serving AP, but on all channels on monitor mode APs.
On the Monitor tab of the WLC web interface, you will find a CleanAir page that will list interferers by bands, as well
as air quality report. Air quality is a metric evaluating the impact of non-Wi-Fi interferers to the current channel: 100
being the perfect clean channel and 0 the worst unusable one.
227
||||||||||||||||||||
||||||||||||||||||||
In the TCP settings page, "Transmit Power Control (TPC)" is selected under RRM of the 802.11a with an
"Apply" button. In the "TPC version" section "Interference Optimal Mode (TPCv2)" radio button is selected.
The "Transmit Power Level Assignment Algorithm" section shows the fields "power Level Assignment Method
radio button is set to Automatic, Maximum Power Level Assignment, Minimum Power Level Assignment,
Power Assignment Leader, Last power level Assignment, and Power Threshold."
RF Profiles
228
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the RF profile window, "RRM" tab is selected that displays the sections "TPC, Coverage Hole to Detection,
DCA, Profile Threshold For Traps, High-Speed Roam, and DCA Channel list." Under DCA, "Enabled"
checkbox is selected for "Avoid Foreign AP interface" and "Best" radio button is selected. In the "DCA
Channel list," a list of channels are shown with the checkboxes selected for the channels "36, 40, 44, 48, 52,
etc." "Enabled" checkbox is selected for "Extended UNIT-2 Channels."
Data Rates
Wireless clients can send each frame at a different data rate. A data rate was originally something easier to remember
229
||||||||||||||||||||
||||||||||||||||||||
The data rates along with spin boxes are listed: 6 Mbps, disabled; 9 Mbps, disabled; 12 Mbps, mandatory; 18
Mbps, supported; 24 Mbps, mandatory; 36 Mbps, supported; 48 Mbps, supported; and 54 Mbps, supported.
Apart from being called “MCS X” rather than using data rates in Mbps, those data rates cannot be mandatory and
therefore have zero effect on management frames. Most people just leave all the 11n and 11ac rates enabled, but you
could, for example, decide to remove support for the highest modulations (like MCS8 and MCS9) so that clients will not
even try these risky modulations and will be less likely to lose frames trying them. This prevents data rate downshifting,
but it is not common practice.
RX-SoP
The strange name RX-SoP stands for Receive (often shortened as Rx) Start of Packet. This feature also does something
that might seem strange at first: reducing the receiver sensitivity of the radio. The idea is that in a dense environment,
we know that there are many roaming candidates for the clients, but sometimes clients will stick to an access point for a
very long time even if the signal is bad. Depending on the Rx-SoP threshold chosen (as illustrated in Figure 4-50), the
AP will choose to ignore packets that come under the corresponding RSSI threshold (which is different on a per-band
basis). In fact, it will not even decode them and will simply consider them as non-Wi-Fi energy.
230
Technet24
||||||||||||||||||||
||||||||||||||||||||
AirTime Fairness
In an attempt to ensure that some less important SSIDs or client types do not abuse the overall bandwidth, many
administrators have the reflex of configuring data rate limiting (also called bandwidth contract). The problem with
bandwidth rate limiting is that it is defined in Mbps usually and does not take into account the amount of clients present
(why restrict speed if there is no one else on the network?) or the usage made by other clients or SSIDs. The lack of
efficiency is particularly in the upstream direction because the client already sent the frame over the air (the critical and
slower part usually), and we would drop it on the AP or WLC because the client already sent “too much,” which
preserves the WAN maybe but not the AP air time. Moreover, in wireless, a slow client using very low data rates (even
if not transmitting huge files) is more annoying to other clients than a client sending a large file but at high data rates,
meaning the transfer will be over quickly.
AirTime Fairness (ATF) focuses on limiting air time rather than specifying a given bandwidth. It is applied only in the
downstream direction (from AP to client) because we cannot honestly control when and if clients can transmit. Each
time the AP has to send traffic on a given WLAN, it will count the airtime consumed by data frames, and when the
“bucket” is full, it can either defer the traffic to send (in a limited buffer) or drop it (which also happens if the buffer
gets full). ATF can be disabled, or enabled in monitor mode (that is, it only counts statistics and does not defer/drop
traffic) or in enforcement mode.
In the Wireless > ATF > Monitoring page (as shown on Figure 4-51), you can configure a specific AP, AP group, or
231
||||||||||||||||||||
||||||||||||||||||||
The monitor configuration under the ATF option from the wireless menu got selected. This displays the ATF
monitor mode configuration page that includes options like AP name, AP group name, network, radio type,
mode that includes enable and disable buttons, and delete radio slot button.
After statistics have been collected, you can consult them in the statistics page in the same menu, as shown in Figure 4-
52.
232
Technet24
||||||||||||||||||||
||||||||||||||||||||
233
||||||||||||||||||||
||||||||||||||||||||
The figure shows a controller-1 having the client database entry, client A: MAC, IP address, AP, QoS, Security
with anchor tag flows to controller-2 having the client database entry, client A: MAC, IP address, AP, QoS,
Security with foreign tag, which represents client entry moved to new controller, anchor and foreign tags
created. Below that, a cloud shows a WLAN controller 1 (left), WLAN controller 2 (right), AP1 (bottom left),
AP2 (bottom right), a laptop below AP1, and another one below Ap2. The flow from WLAN controller 1 to
WLAN controller 2 via IP tunnel with ethernet connection represents the exchange of mobility messages.
Further, the flow from WLAN controller 1 to AP1 via CAPWAP tunnel and to the left laptop indicates pre-
roam data path that represents data traffic bridged from or to VLAN x, the flow from WLAN controller 2 to
AP2 via CAPWAP tunnel and to the right laptop indicates post-roam data path that represents data traffic
234
Technet24
||||||||||||||||||||
||||||||||||||||||||
A prerequisite to roaming is that WLCs know each other, so they can exchange information about clients. This
prerequisite also means that the WLCs must be in the same mobility group, or mobility domain (the two terms mean the
same thing). A mobility group is a set of controllers, identified by the same mobility group name, that defines the realm
of seamless roaming for wireless clients. Controllers in the same mobility group can share the context and state of client
devices, as well as their list of access points, so that they do not consider the access points of each other as rogue
devices.
To make two controllers members of the same mobility group, you need two steps:
1. Input the same string in the Controller > General > Mobility Domain Name field, so that both controllers have
the same mobility group/domain value (CLI config mobility group domain).
2. Inform each controller about the other in Controller > Mobility Management > Mobility group. Each controller
needs to know the other controller’s management IP address and built-in MAC address (CLI config mobility group
member add <MAC> <IP> <group>).
As a side effect of roaming, if you want roaming to occur smoothly, you should run the same code on both controllers
(so that they speak the same language and understand the same options). Without this precaution, one WLC may share
information about an option that the other WLC does not understand. You can verify the compatibility between WLC
codes on this page:
https://www.cisco.com/c/en/us/td/docs/wireless/compatibility/matrix/compatibility-matrix.html
However, compatibility does not mean that all features will be the same.
Additionally, you should also configure the same virtual gateway IP address (this address is used as a “virtual address”
to make the client think that it connects to one big virtual controller instead of several physical controllers).
Mobility groups can contain up to 24 WLCs. However, a WLC can know about other WLCs with a different mobility
group name configuration. As WLCs know one another, they are in each other’s mobility list. However, as their
mobility group value is different, they are in different mobility groups. Figure 4-54 shows such an example, where a
WLC in mobility group Mygroup is connected to two other WLCs, one in the same mobility group and one in another
mobility group (none). Both 172.31.255.30 and 172.31.255.19 are in 172.31.255.40’s mobility list, but only
235
||||||||||||||||||||
||||||||||||||||||||
Mobility Messaging
When an STA joins an SSID on an AP, the associated WLC tries to discover whether the client is roaming. For that
purpose, the new (foreign) WLC checks whether the STA is known locally (entry in the WLC client database). If the
STA is not known, the WLC sends a mobile announce message to all WLCs in its mobility list (same mobility group or
not). The mobile announce includes the STA MAC address. A WLC that knows the client (prior, or anchor controller)
responds with a mobile handoff message that passes the STA context to the new WLC. The WLCs use a mobility
control tunnel to exchange this information, running on port UDP 16666. In the case of a Layer 3 roaming, the STA
data will continue to flow through the WLCs using an EoIP tunnel. The choreography is displayed in Figure 4-55.
236
Technet24
||||||||||||||||||||
||||||||||||||||||||
The layer 2 roaming exchange shows a client sends a request to the old controller which in turn sends DATA to
the client. Step 1 shows the client sends the association request to the new controller. Step 2 shows the new
controller sends the association response to the client. Step 3 shows the new controller sends mmMobile
announce to old controller. Step 4 shows the old controller sends mmMobile handoff to the new controller. At
last, the client sends the request to local which in turn sends DATA to the client. The layer 3 roaming exchange
involves the same steps but at last the client sends the request to foreign which in turn sends the request to
anchor, where the anchor sends back (EOIP) DATA to foreign which in turn sends DATA to the client.
You should note that a new mobility mode, using CAPWAP encapsulation instead of EoIP, is available since AireOS
code 7.3. This type of mobility creates a hierarchical structure (with mobility agents and mobility controllers). This
mode is not functionally very different from the traditional (or flat) mode described here. In the context of the CCIE lab
exam, this new mobility is not covered anymore, and in real life, the traditional mode is more common.
This mobile announce occurs for each new STA. By default, an individual message is sent to each other WLC. Such
exchanges can create a lot of traffic on active networks. To simplify the flow, you can configure multicast messaging
between WLCs from Controller > Mobility Management > Multicast messaging (CLI config mobility multicast
enable family of commands). This configuration supposes that your wired network is also configured to support
multicast communications. By default, multicast is not forwarded across subnets.
With multicast messaging, your WLC sends one mobile announce to the multicast address. The other WLCs have
subscribed to the same multicast group and receive the message. The process creates fewer strains on the wired part of
your network.
You can configure a different multicast address for each mobility group known by the WLC. In Figure 4-56, the WLC
has two different multicast addresses configured, one for each mobility group (239.5.5.5 for the local Mygroup mobility
group and 239.5.5.6 for the none mobility group).
237
||||||||||||||||||||
||||||||||||||||||||
The multicast address can be the same for more than one (or all) mobility groups. The decision depends on your
mobility design. For example, if your network has two mobility groups, and WLCs for each group are in different areas
of your network, you may want to configure different multicast addresses. If WLCs are in the same area (same group of
subnets), a single multicast address is likely sufficient to reach them all while avoiding duplicates.
All the WLCs in the same mobility group should be configured with the same mobility multicast settings. The address
you configure is used to send mobile announce messages, but the WLC will also subscribe to the traffic sent to that
address, so as to receive the mobile announce from the other WLCs.
Mobility Anchors
There are cases where you always want traffic to be sent to a specific WLC. A common scenario is guest networking,
where a WLC is in the DMZ, and all client traffic for the guest SSID should be forwarded there, to avoid guest traffic to
stay in the corporate network. To achieve this goal, you need to configure a mobility anchor information from the
WLAN main page, for the target WLAN, as shown in Figure 4-57 (CLI config mobility group anchor family of
commands).
The WLAN options from the WLANs menu is selected. This displays the WLAN main page that includes
238
Technet24
||||||||||||||||||||
||||||||||||||||||||
Troubleshooting Mobility
The most common issue affecting inter-WLC mobility (Layer 2 or Layer 3 roaming, and auto-anchoring) is a mismatch
in configuration that causes the mobility tunnel to fail. The debug mobility handoff enable command (along with
debug client <MAC> to filter the output to only the client of interest) will show everything you need to know. For
example:
Click here to view code image
(Cisco Controller) >debug mobility handoff enable
||||||||||||||||||||
||||||||||||||||||||
Band Select
When wireless clients start an association or a roaming (reassociation) event, they scan for APs around, looking for the
best connection quality, with preference to current SSID (or the SSID selected if it was initial association) or to known
SSIDs, and sometimes preference to current radio bands. This client scanning in its most basic form is passive (by just
hearing APs’ beacons in supported channels while scanning them, with each radio if dual-band client) and active (by
proactively transmitting 802.11 probe requests on supported channels waiting for probe responses from APs).
802.11 beacons and probe responses from APs (along with the signal quality in which they are perceived) are the
minimum information that 802.11 wireless clients use from that scanning activity to decide what AP to select when
associating or reassociating.
The purpose of the Band Select or Band Selection feature in AireOS is to manipulate AP’s probe responses in an
abnormal, out of the standard way, trying to influence the clients to select the AP in the 5 GHz band instead of the 2.4
GHz band (no need to discuss in this section of the book why the 5 GHz band, if available with similar or higher signal,
is a better option than 2.4 GHz). This is why the feature is not based on a standard and doesn’t rely on the client
“supporting” the feature. It is actually a WLAN infrastructure (WLC/AP) feature based on a specific algorithm
performed to change the behavior of the 802.11 probe responses.
In summary, the way it works is that probe responses in the 2.4 GHz band are suppressed, while the ones in the 5 GHz
band are transmitted normally by the APs in response to probe requests, hoping that the client will prefer the 5 GHz
band in the absence of probe responses in the 2.4 GHz band. Nowadays, latest dual-band wireless clients normally
prefer the 5 GHz band, but there are still many clients that sometimes prefer the 2.4 GHz connection, even when the
availability of 5 GHz APs/BSSIDs is still a good option. Therefore, with this feature enabled at the WLAN/SSID level in
the WLC with the command config wlan band-select allow enable wlan_ID, wireless clients will hopefully choose the
5 GHz band.
The specific behavior of the feature depends mainly on whether the client is dual-band and its RSSI (the client’s signal
240
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Load Balancing
Formerly known as aggressive load balancing, this is another WLAN infrastructure proprietary feature that doesn’t
require any type of client support or configuration; however, it relies on specific 802.11 frames with the expectation
that the client will understand that it should make a better decision (look for another AP that is less busy). The main
purpose of the feature is to prevent clients from associating or roaming to busy APs if there are other APs around the
area that are not as busy, trying to forcefully balance (by denying (re)associations) the load of wireless clients in
coverage areas where more than one AP is available for the client to associate or roam. The way the WLAN
infrastructure achieves this purpose is different depending on the AP mode:
Local mode AP: When the wireless client sends the 802.11 Association Request to the AP it decided to associate
or roam to, but the WLC considers that this AP is busier than another AP available for this client (based on the
feature logic, which we cover later), the AP will reply with an 802.11 Association Response using status code 17,
which basically indicates that the AP is busy, and literally denies the client’s association attempt to this specific AP,
hoping that it will immediately reattempt the (re)association with another AP.
FlexConnect mode AP: When the APs are in FlexConnect mode, they handle some decisions locally, such as the
802.11 (re)association handshake, which happens at the AP level instead of sending requests up to the WLC and
waiting for the responses, because this could cause, for example, severe failures due to possible latency (or drops)
in the path between the FlexConnect AP and the WLC. Hence, FlexConnect APs initially send a (re)association
response with status code 0 (success) to the client while sharing the association attempt with the WLC and waiting
for it to calculate the load-balancing decision (this happens at the WLC level in order to consider the current load of
all the APs that this client can hear during that attempt). After calculations, if the WLC considers that this client
should be denied in that specific AP trying to balance the load to another AP, then an 802.11 deauthentication
frame with reason 5 is sent to the client, again, hoping that the client will attempt its next (re)association with a less
loaded AP.
The load balancing algorithm denies clients, in any of the two ways explained previously, if it considers that an AP is
busy. You can manipulate why an AP is considered busy based on two modes:
Client count: With the command config load-balancing window <client_count>, you configure the load-
balancing “window size,” which is used to derive the actual threshold that determines, in each association attempt,
whether an AP is busy due to client load when compared with other APs available for the client to also
associate/roam. The amount of clients in the less loaded AP available for that client is the base of the equation, and
the window value is the ratio with the threshold (APs with more clients than the threshold are considered busy). For
example, if the config load-balancing window value configured is 5, and a client is trying to associate to AP1
(currently with 16 clients), but AP2 (with 13 clients) and AP3 (with 10 clients) are also available for that client, the
less loaded AP available is AP3. Hence, with base client-count from AP3 as 10 + window 5, the threshold is 15.
Based on this threshold, AP1 is busy, so the association is denied, expecting the client to make a better decision
trying to associate to AP3 or at least AP2, because these APs are not considered busy in this area (at least not busy
based on client count).
AP Uplink usage: When this mode is used, an AP is considered busy if the uplink interface of an AP is reporting
utilization (in percentage) equal or higher than the one configured with the command config load-balancing
uplink-threshold <traffic threshold>. The default value of the threshold is 50, so if the utilization of an AP uplink
242
Technet24
||||||||||||||||||||
||||||||||||||||||||
This load-balancing method definitely affects roaming behavior, and that’s why we are covering the feature in this
section of the book. Imagine a client trying to roam to a busy AP, where the reassociation is always denied, and the
client is unfortunately not smart enough to attempt an association with a less loaded available AP, so it keeps trying and
failing at a level that completely disrupts the roaming. When such persistent devices (or devices that can’t process
appropriately responses with status code 17) are critical clients in your WLAN, or there are critical mobile devices using
real-time services, it is not recommended to use this feature (disable it at the WLAN where those clients connect).
For very persistent devices, (re)association still needs to happen at some point, even if they are not critical clients.
Hence, you can configure the maximum denial count with the command config load-balancing denial
<denial_count>. With the default value of 3, the client experiences three association failures when trying to connect to
a busy AP, but the next association attempt will be allowed.
Optimized Roaming
This is another Cisco proprietary feature that doesn’t require anything at the client side, but simple configuration at the
WLC level. It is a wireless LAN controller global setting that can be applied per band (not per WLAN), and affects all
types of clients as long as they meet the criteria to get optimized roaming applied.
This feature is similar to the load balancing feature, but their main difference is that load balancing affects client
(re)association based on current AP load of clients, whereas optimized roaming affects client (re)association based on
the client’s signal quality (RSSI, but data rate can optionally be considered). Another important difference is that the
optimized roaming intention is to affect mainly wireless clients that have the “sticky” behavior of staying connected
with current AP, even when the signal quality with that AP is going bad and other better APs are available (which is bad
not only for this specific client but for the entire channel, because a client with bad performance, collisions,
retransmissions, low data-rates, and so on also affects the performance of all other clients/APs using that channel).
How does that happen? How does optimized roaming affect client (re)association when a client’s signal quality is
considered poor? There are two ways to achieve this:
Disassociations: In this scenario, the client is already associated; it is actually passing traffic and not trying to roam
even when it should (due to current signal quality). Hence, WLC forces the client to roam to a better AP by
proactively sending an 802.11 Deauthentication frame with reason code 7, such as the one shown in the packet
capture of Figure 4-58.
243
||||||||||||||||||||
||||||||||||||||||||
The screenshot reads, frame 14785, radiotap header v0, length 18, 802.11 radio information, IEEE 802.11
deauthentication with flag information (expanded), IEEE 802.11 wireless LAN (expanded). In which, the
IEEE 802.11 deauthentication with flags shows the type that reads deauthentication (0x000c), frame
control field, receiver address, destination address, transmitter address, source address, frame check
sequence. The IEEE 802.11 wireless LAN shows fixed parameters that include reason code that reads class
3 frame received from nonassociated STA (0x0007).
Rejections: When attempting a new connection, during brand new association or roaming (reassociation) events, if
the client tries to (re)associate to an AP with poor RSSI perceived by the AP, its association will be rejected with an
802.11 association response with status code 34, such as the one of the packet capture in Figure 4-59. This is
exactly what will happen if the client tries to rejoin the same AP after getting proactively removed by the AP, as
explained in the previous scenario (“Disassociations”). In fact, this type of association rejection will continue if the
client keeps trying to rejoin the same AP, unless the client’s RSSI increases (per AP perception) 6dBm or more
above the RSSI threshold.
Technet24
||||||||||||||||||||
||||||||||||||||||||
Number of Data Packets Received: This is the minimum number of packets that must be received from the client
(at any RSSI level, good or bad) to trigger client disassociation if previous conditions are met. This is also a CHD
threshold, and the command to configure this value is config advanced 802.11<a/b> coverage packet-count
<num-packets>.
Roaming Data-Rate Threshold: This one is optional and is disabled by default. When used, optimized roaming
will apply disassociations only to clients connected at this data rate or lower. It is a good option if low or legacy
rates are enabled, and some sticky clients stay connected at those low data rates far away from the AP. When
disabled, optimized roaming applies to all clients meeting the criteria to be disassociated regardless of its data rate.
This can be configured with the optimized-roaming command config advanced 802.11<a/b> optimized-roaming
datarate <mbps>.
Optimized Roaming Interval: This is the time interval at which each AP reports the client statistics to WLC so it
can calculate with the optimized roaming algorithm (using previously explained thresholds) if a client disassociation
must be triggered or not. This is also configurable with an optimized-roaming command config advanced
802.11<a/b> optimized-roaming interval <seconds>.
Let’s use the example with the default values to better explain when exactly an optimized roaming disassociation will be
triggered:
If optimized roaming is enabled and more than 25% (coverage data fail-percentage) of at least 50 packets (coverage
packet-count) in a fixed 5 second period were received at −80dBm of RSSI or lower (coverage data rssi-threshold)
from a client already associated, the AP will disassociate the client when the reporting interval of 90 seconds expires
(optimized-roaming interval).
245
||||||||||||||||||||
||||||||||||||||||||
These are two IEEE 802.11 standard amendments that help to optimize client roaming. They are implemented by
AireOS, which has them enabled by default when creating a WLAN/SSID, so wireless clients connecting to such a
WLAN and officially supporting these standards will take advantage of their benefits. Using 802.11k and 802.11v is a
recommended best practice and is suggested instead of proprietary methods like the load balancing and optimized
roaming explained before, mainly as AireOS implements 11k and 11v with similar behaviors to those other features.
The way these two methods are implemented in AireOS is explained deeper in Chapter 7, “WLAN Media and
Application Services,” so we are not covering all the details in this chapter; we just wanted to mention both in this
section so it is clear to you that these are two very important methods to optimize client roaming decisions, specifically
by suggesting better APs. Refer to Chapter 7 for more details, and for now, we will share a summary of how they work,
mainly when compared to the methods already explained in this section.
As explained earlier, wireless clients spend some time and effort (including battery usage, for example) scanning for the
best AP to (re)associate, based on active and passive scanning. This scanning and AP selection can be greatly improved
if the client is suggested with specific APs (and their channels) as its best options to roam to, not only suggesting the
best next option but also reducing the time-effort it takes for a client to make this decision while scanning. This
improves a lot the performance during the roaming process for mobile devices, mainly with real-time applications; for
example, instead of scanning all channels looking for the best option to roam to (remember that, while scanning, the
client is perhaps on a live voice call moving away from its current AP cell at the speed of the user walking, and while
this is happening, the signal quality of the current AP connection is getting worse, so call quality is probably getting
affected), the client might only scan the three channels of the three specific APs suggested by the WLC.
The main purpose of these two standard methods in optimizing client roaming decisions is to suggest the client with the
best candidates of APs where it could roam to when necessary, so the client can finally make a smarter and more
efficient decision.
This is achieved with 802.11k by having the client proactively sending a neighbor report request to its current AP, and
the AP replying back with a neighbor report response suggesting the best APs (a list of APs that is built by a complex
algorithm at the WLC that can consider multiple factors and technologies, such as RRM neighbor information, signal
between APs in the area, current AP location, floor information from Prime Infrastructure, and roaming history). After
that exchange, the 802.11k client will look for the best AP from that list when it is time to roam.
Note
AireOS implements an optional variant known as Assisted Roaming for Non-802.11k Clients or Assisted Roaming
Prediction Optimization, which is the option for clients that don’t support the standard 802.11k. This one is explained in
Chapter 7.
246
Technet24
||||||||||||||||||||
||||||||||||||||||||
Fast-Secure Roaming
802.11 wireless roaming events happen every time a wireless client moves from one AP to another AP, and every time
such roaming happens, the wireless client needs to perform full new association and authentication with the WLAN
infrastructure. The new association is actually a reassociation event (an exchange with the AP/WLC of reassociation
request and reassociation response frames), and if the SSID is configured with WPA/WPA2 security, the WPA level
authentication needs to happen again, as well as the WPA 4-way handshake required to derive new encryption keys (so
encryption can happen with the new AP).
You can imagine the overload of authentication events happening in a secure mobile environment where wireless clients
are constantly roaming (with a high amount of hits in the RADIUS server). In addition, there is something very critical
happening while roaming: a period of time in which the wireless client cannot pass any traffic (data frames) at all. This
is because it needs to go again through that mentioned process, as soon as it sends the reassociation request to the
selected AP it is roaming to, before it can transmit or receive again any other data frame. It reassociates, then performs
EAP authentication again with the RADIUS server, and finally completes the WPA 4-way handshake to derive new
keys. Figure 4-60 demonstrates all the frames exchanged between the client and AP/WLC on a roaming event with
WPA2/EAP authentication, before the client can continue passing data frames.
247
||||||||||||||||||||
||||||||||||||||||||
The screenshot shows the set of twenty frames that includes information like frame number, time, source,
destination, BSSid, protocol, channel frequency, and info. In which, the frame 19 reeds, 1.125063, Cisco_f0:
2a: 98, Aironet_b7: ab: 5c, 84: 78: ac: f0: 2a: 98, 802.11, 2437, and QoS Data, SN=76, FN=0, flags= .p . . .F. C.
It concludes this frame is the first data frame after roaming.
As you can see in Figure 4-60, the first data frame after the roaming event is frame number 19, and the amount of
authentication frames during the EAP exchange could be higher depending on the EAP method and its settings. The fact
is that several frames are required before the client can continue passing traffic, and this takes some time, which could
be longer if there are big delays between AP and WLC, for example, and/or WLC and RADIUS server, or drops and
retransmissions, or server not responding, and many other variables. The behavior just explained is normal and the way
this WPA2/EAP security works; wireless clients must be “validated” again when moving to a new AP, and new
encryption keys are required for security reasons. However, this can heavily impact the wireless user experience during
roaming, mainly if running a sensitive application/service at the mobile device where timeouts can happen or traffic
could be lost (for example, some audio missing during a voice call).
Fast-Secure roaming methods were invented to accelerate this normal process explained and shown in Figure 4-60.
When a wireless client and AP/WLC apply a supported Fast-Secure roaming method, a secure roaming (with
WPA2/EAP, for example) can be faster, using caching techniques to avoid a new EAP authentication handshake
against a RADIUS server (hence also reducing server and network load), and sometimes even avoid the WPA 4-way
handshake (while still deriving new encryption keys).
This topic is one of the roaming optimization features that require support in both the client side and the AP/WLC side.
There are multiple Fast-Secure roaming methods available, and the Cisco WLAN infrastructure (AP/WLC) supports
most of them, but most wireless clients support only one method (and some clients don’t even support one, so you need
to confirm what your client devices support if you are trying to implement or troubleshoot Fast-Secure roaming). Some
of the methods are not really a standard (so few devices support it), some are proprietary (like CCKM from Cisco), and
there is one official standard method defined by the 802.11r amendment that looks for massive adoption (officially
named Fast BSS Transition and known as FT or just 802.11r).
We are not covering all the Fast-Secure roaming methods supported by AireOS, but just briefly the two methods widely
used in Cisco WLAN infrastructures (and that you must fully understand for the CCIE exam): CCKM and 802.11r/FT.
Note
There is a complete Cisco article that covers in depth all of the Fast-Secure roaming methods; it explains the working
details and variants of each method, pros and cons, differences, and more. It demonstrates with wireless packet captures
and WLC debugs the flow and handshake for every single method, explaining the meaning of the debugs and important
frames/fields found in the wireless captures, to help you not only implementing a Fast-Secure roaming method when
applicable, but to also understand and troubleshoot deeply any roaming or Fast-Secure roaming event.
248
Technet24
||||||||||||||||||||
||||||||||||||||||||
CCKM
Cisco developed Cisco Centralized Key Management (CCKM) as the first Fast-Secure roaming method that could avoid
EAP authentication and key management handshake during roaming events on an 802.11 WLAN using security with
802.1X. Only Cisco wireless clients (such as the IOS Autonomous WGBs and older Cisco VoIP phones) and some third-
party clients that are Cisco Compatible Extensions (CCX)-compatible support CCKM.
CCKM works on top of an 802.1X/EAP authentication method to cache the secured session at the client and a
centralized WLAN device (in this case, the AireOS WLC) during the client’s first association/authentication. With this
caching technique, the client avoids EAP authentication when it reassociates (roams) to another AP managed by that
centralized device, because the session is still valid (cached).
In addition, remember that when EAP authentication is used in Wi-Fi, some type of encryption is required to secure the
data frames of the authenticated session, so CCKM also deals with the encryption by performing special key-
management techniques that help to derive encryption keys for all known encryption types (WEP, TKIP, and AES-
CCMP). That means that you configure CCKM to use it when EAP authentication is implemented with WEP
encryption, with WPA/TKIP, or with WPA2/AES. Today, most wireless clients that still use CCKM support it with
WPA2/AES, which is the most secure, and is configured (using the GUI) in the AireOS WLC WLANs/SSIDs, as shown
in Figure 4-61.
249
||||||||||||||||||||
||||||||||||||||||||
The screenshot shows the set of six data frames that includes information like frame number, time, source,
destination, BSSid, protocol, channel frequency, and info. In which, the data frame 5 reeds, 0.843240,
Aironet_b7: ab: 5c, broadcast, 84: 78: ac: f0: 2a: 93, 802.11, 2437, and QoS Data, SN=2717, FN=0, flags= .p . .
.TC. It concludes, after roaming this data frame continues in the network for the client.
As you can see in Figure 4-62, after the wireless client and AP/WLC exchange those initial four 802.11 management
frames, 802.11 data frames can continue in the network for this client. This is very fast because those four management
frames are always required to join an AP and happen quickly (Open System Authentication from the client, another
back from the AP, then (re)association request, and (re)association response), so the client is immediately passing data
frames without much delay as soon as it moves to the new AP.
802.11r/FT
This is the actual 802.11 standard amendment that provides the guidelines to perform Fast BSS Transitions (fast
roaming) when a WLAN is using security. Enterprise WLANs had implemented a few other Fast-Secure roaming
methods (such as CCKM) before FT was officially ratified in 2008, so it had a slow adoption, but it is nowadays the
embraced method for mobile devices, and the recommended one (unless CCKM is required for clients that do not
support 802.11r).
802.11r performs a job similar to CCKM, because it avoids both the EAP authentication and the key-management
handshakes, but it works only for WPA2/AES because this standard is for 802.11i RSN (Robust Security Networks).
Because of the way its key caching techniques and key hierarchies are implemented (out of the scope of this book),
802.11r also takes advantage of Fast-Secure roaming for WPA2-Personal (PSK) and not just WPA2-Enterprise (EAP),
making WPA2-Personal roaming even faster by avoiding the WPA2 4-Way handshake.
250
Technet24
||||||||||||||||||||
||||||||||||||||||||
The screenshot shows a set of frames that includes information like time delta, source, destination, ch. freq,
rate, signal dB, protocol, length, and info. In which, the frame 22 reads, 0.002388, Cisco_f0: 68: d6, broadcast,
2462, 1, negative 10 dBm, 802.11, 287 Beacon frame, SN=2638, FN=0, flags=. . . . . . C, BI=102, and
SSID=FT-EAP-OTA. Below that reads, frame, radiotap header v0, length 18, 802.11 radio information, IEEE
802.11 wireless LAN (expanded). The IEEE 802.11 wireless LAN highlights few fields such as tag: RSN
information, type: FT over IEEE 802.1X, tag: mobility domain, and fst BSS transition over DS: 0X0.
As you can see from the highlighted sections of the beacon frame, this AP is advertising required support for FT within
the RSN Information Element; specifically saying that the Authentication Key Management (AKM) type supported
requires FT with 802.1X (doing an EAP method). There is also a Mobility Domain Information Element with further
details and capabilities used by FT in this BSS (as 802.11r supports multiple variants).
In summary, the following are the FT variants supported by Cisco WLCs, and the way you can configure them using
CLI commands:
251
||||||||||||||||||||
||||||||||||||||||||
During a roaming event, wireless clients can perform Fast BSS Transitions in two ways: the most used and
recommended method is known as “Over-the-Air.” With this method, the client starts FT roaming against the target
AP it is roaming to, by exchanging with this new AP the typical 802.11 Open System Authentication frames but that
this time contain FT information used to perform the Fast-Secure roaming (based on initial FT association exchange
and cached session that happened when the client first joined the WLAN).
The other method is to perform FT “Over-the-DS” (Distribution System). In this case, the client sends an FT Action
Request frame to its currently associated AP containing FT information (which has the target AP it is roaming to),
so its current AP can send this request to the target AP over the distribution system (in this case, through the WLC),
which sends back to the client an FT action response frame. After that exchange (which achieves basically the same
purpose as the Open System Authentication exchanged when doing Over-the-Air), the client can initiate the Fast-
Secure roaming with the target AP by exchanging reassociation frames (now over the air, as usual). Only one of the
two methods is allowed per SSID, and they are configured with the command config wlan security ft over-the-ds
{enable | disable} wlan-id. When using the disable version of the command, you configure the method Over-the-
Air.
FT for SSIDs with WPA2 Enterprise (with 802.1X/EAP), configured with the command config wlan security wpa
akm ft 802.1X enable wlan-id.
FT for an SSID doing WPA2 Personal (with PSK). In this case the command is config wlan security wpa akm ft
psk enable wlan-id.
FT can also be optional for the clients connecting to the SSID, also known as “mixed mode” (or “hybrid mode”),
where clients are supposed to connect doing the WPA2 method configured, even if they don’t support 802.11r.
Clients that support 802.11r will negotiate it during the association, but clients that do not support it are supposed to
do regular WPA2/EAP. Unfortunately, some old clients don’t behave as expected and might fail to associate to an
SSID configured in this “mixed mode” advertising both methods (this is why it is not recommended to use mixed
mode, and the reason why FT in adaptive mode was developed with Apple). For example, in this mixed mode,
regular 802.1X/EAP is advertised and allowed (configured in the SSID with the command config wlan security
wpa akm 802.1x enable wlan-id), while 802.1X/EAP with FT is also advertised and allowed (configured with the
command previously explained, config wlan security wpa akm ft 802.1X enable wlan-id). The same can be done
for PSK.
Figure 4-64 is a wireless packet capture example of a Fast BSS Transition happening Over-the-Air for an RSN
association with WPA2 Enterprise (802.1X/EAP) in an SSID that allows only clients that support FT in this mode (so no
mixed mode configured).
252
Technet24
||||||||||||||||||||
||||||||||||||||||||
The screenshot shows a set of frames that includes information like time delta, source, destination, ch. freq,
rate, signal dB, protocol, length, and info. In which, the frame 4 reads, 0.006901, Cisco_f0: 2a: 96, Apple_15:
39: 32, 2437, 1, negative 30 dBm, 802.11, 326 reassociation response, SN=793, FN=0, flags=. . . . . . C. Below
that reads, frame 4, radiotap header v0, length 18, 802.11 radio information, IEEE 802.11 Reassociation
response with flag information, and IEEE 802.11 wireless LAN (expanded). The IEEE 802.11 wireless LAN
highlights few fields such as tag: RSN information, tag: mobility domain, and tag: fast BSS transition.
As you can see from Figure 4-64, just like in CCKM, only the four (always required) initial management
authentication/reassociation frames are exchanged with the AP before the client can continue passing data frames,
avoiding both the EAP handshake and also the key-management handshake. FT Authentication and AKM happen
during the exchange of those four frames, because all those four frames contain FT material that help to validate the
cached FT session and derive the new encryption keys. In fact, the first two Authentication frames are not regular Open
System Authentication frames but Fast BSS Transition Authentication frames, where the FT handshake starts.
In Figure 4-64, the Reassociation Response frame from the AP (which confirms that the Fast BSS Transition was
successful and finishes the FT handshake) is selected from the packets captured to show the highlighted three
Information Elements (IE), which are the ones that contain the FT details exchanged within those four management
frames during the roaming event. The first two IE are the ones explained earlier (advertising the FT mobility domain
details and capabilities, as well as the support for Over-the-Air with 801.X), and the third is the Fast BSS Transition IE,
which contains most of the information of this client’s FT session and the key material used to derive the new
253
||||||||||||||||||||
||||||||||||||||||||
Summary
This chapter is likely one of the longer and more critical for your exam preparation. Because the WLC is at the core of
the wireless expert daily activity, you are expected to know each of its functions in detail. You should understand and
be able to explain in simple terms each option present in the WLC GUI and each CLI command. You should also be
aware that some advanced functions are not available in the GUI. This limitation does not mean that you should ignore
the GUI and focus solely on the CLI (although this is definitely a possible path). However, you should be comfortable
enough with the CLI to “survive” the requirement to configure a function without the assistance of the GUI.
Additionally, keep in mind that experts are not commonly called to perform simple or common configuration tasks. In
most cases, experts are needed to realize uncommon combinations or troubleshoot issues that less-skilled professionals
could not solve. These requirements mean that you should be able to use debug commands to observe the effect of your
configurations. You should know what messages are expected when your configuration is activated, and what messages
appear when things go wrong. A good way to prepare is to voluntarily misconfigure items (the WLC or the client side)
and observe the resulting debug messages. Investing the time needed to acquire this understanding will save you time
later. In most troubleshooting scenarios, whether in the lab or in real life, pressure is high to fix the issue as fast as
possible, and familiarity with the debug outputs is often a key to troubleshooting efficiency.
254
Technet24
||||||||||||||||||||
||||||||||||||||||||
802.1X
IEEE STD 802.1X-2010 is a protocol framework for Layer 2 access control that offers the capability to permit or deny
network connectivity based on the identity of the end user or device. It uses a controlled/uncontrolled virtual port model,
shown in Figure 5-1, to block general data over the controlled port before authentication completes successfully over the
uncontrolled port that only allows EAP authentication traffic. After the controlled port is authorized, it unblocks to allow
passing data.
Two figures are shown for the port behavior, before authentication and after authentication. The before
authentication figure shows the laptop user is unknown and so the DHCP, TFTP, KRB5, and HTTP are blocked by
the protocol framework and only the EAPoL is allowed. The after authentication figure shows the laptop user
named George is allowed through the protocol framework to reach the DHCP, TFTP, KRB5, HTTP, and EAPoL.
On a wireless LAN, each association between a client and the access point creates a unique pair of 802.1X virtual ports.
After authentication has completed, not only the flow of frames is permitted but cryptographic keys are generated to
protect the frame transfer.
802.1X Components
As specified in the standard and shown in Figure 5-2, 802.1X defines the following three required components:1
255
||||||||||||||||||||
||||||||||||||||||||
Authenticator: The network device that controls access to the network and facilitates the authentication process by
relaying the credentials of the supplicant to the authentication server.
Authentication server: A server responsible for validating the credentials sent by the supplicant and determining the
network access level that it should receive.
The components include a supplicant, authenticator, and an authentication server. The supplicant (client)
sends a request to authenticator through the wireless connection which in turn sends the request to the
authentication server. Both the authenticator and authentication server placed in a secured network.
EAP
The Extensible Authentication Protocol (EAP), described in IETF RFC 3748, provides a flexible authentication framework
which supports multiple methods that are negotiated and used to mutually authenticate the supplicant and the
authentication server. EAP messages between the supplicant and the authenticator run directly over the data link layer
using EAP over LAN (EAPoL) encapsulation as defined by the 802.1X standard. The authenticator will then extract the
EAP payload from the EAPoL frame and relay the message to the authentication server by encapsulating it inside a
RADIUS packet. This message exchange using different transport protocols is represented in Figure 5-3.
The supplicant sends an EAP message to authenticator through EAP transport protocol over LAN labeled
"EAPoL" which in turn sends the message to the authentication server by encapsulating it inside a RADIUS
256
Technet24
||||||||||||||||||||
||||||||||||||||||||
Success: This packet is sent by the authenticator to the supplicant after successful completion of an EAP
authentication method.
Failure: The authenticator will use this packet if it cannot authenticate the supplicant.
EAP Methods
EAP provides the flexibility to support different methods that define the type of credentials and how they are submitted
from the supplicant to the authentication server using the EAP framework. Although multiple EAP methods are available,
we will cover at a high level the three that are more commonly deployed.
EAP-FAST (EAP—Flexible Authentication via Secure Tunneling): Developed by Cisco and published as an
informational document in IETF RFC 4851, EAP-FAST enables mutual authentication by using a shared secret, called
Protected Access Credential (PAC), to establish a TLS tunnel that will secure the exchange of user authentication
messages. As shown in Figure 5-4, EAP-FAST has three phases. During Phase 0 (which is optional and prevents
manual out-of-band distribution of PACs), the PAC is automatically provisioned in-band on the supplicant using either
an anonymous TLS handshake (using the Authenticated Diffie-Hellman Protocol) or via an authenticated tunnel using
the server certificate. During Phase 1, the PAC is used to perform mutual device authentication, and a TLS tunnel is
established. Finally, in Phase 2, user authentication credentials are passed securely within the TLS tunnel created in
Phase 1. Several inner methods (MS-CHAPv2 for credentials or EAP-TLS for certificates) are available for EAP-
FAST, which makes it very flexible.
The supplicant sends the user credentials to authenticator through the wireless connection which in turn sends
the credentials to the authentication server. Below that shows the exchange of user authentication messages
through three phases: Phase 0 (optional) includes an A-ID secure key that represents Protected Access
Credentials (PAC) shows, Diffie-Hellman exchange or via TLS server-side authentication, Phase 1 shows the
257
||||||||||||||||||||
||||||||||||||||||||
The supplicant sends the certificate signed by Certificate Authority (CA) to authenticator through the wireless
connection which in turn sends the certificate to the authentication server. Below that shows, the server sends
its certificate to the client for validation, that indicates TLS channel established for authentication. A checklist
about server certificate indicates, signed by trusted CA and allowed server.
EAP-TLS (EAP—Transport Layer Security): Described in IETF RFC 5216, this method offers mutual
authentication between the supplicant and the authentication server through the exchange and verification of X.509
certificates. This authentication process relies on not only the supplicant and authentication server having their own
certificate, they each need to have a copy of the root certificate from the certificate authority (CA) that signed their
peer’s certificate. During the EAP-TLS exchange, illustrated in Figure 5-6, the authentication server first submits its
certificate to the supplicant to be validated. After the identity of the authentication server has been verified, the
supplicant submits its certificate and the authentication server validates it, completing the process of mutual
authentication. EAP-TLS is available as a standalone method, and also as an inner method for PEAP, which makes it
even more secure because there is first an anonymous PEAP tunnel for encryption, and the full EAP-TLS exchange
that follows is fully encrypted. That’s a TLS tunnel inside another TLS tunnel.
258
Technet24
||||||||||||||||||||
||||||||||||||||||||
The supplicant sends the certificate signed by Certificate Authority (CA) to authenticator through the wireless
connection which in turn sends the certificate to the authentication server. Below that shows, the server sends
its certificate to the client for validation and the client sends its certificate to the server for validation. A
checklist about server certificate indicates, signed by trusted CA and allowed server whereas the checklist
about client certificate indicates, signed by trusted CA and valid.
RADIUS
The Remote Authentication Dial-In User Service (RADIUS) is a protocol used to control network access defined in IETF
RFC 2865 (authentication and authorization) and RFC 2866 (accounting).
RADIUS operates in a client/server model with the following entities:
Network Access Server (NAS): Responsible for passing user information to the RADIUS server and acting upon the
response that is returned.
RADIUS Server: Responsible for processing the access request and returning all required parameters for the NAS to
provide access to the user.
The transactions between the NAS and the RADIUS server are protected by the use of a shared secret and are transported
over UDP on port 1812 (authentication) and 1813 (accounting). This communication takes place using six main packet
types:
Access-Request: The NAS sends these packets to provide the server with the information required to assess whether
the user will be granted access.
Access-Accept: The RADIUS server sends these packets to provide the NAS with the information required to allow
access to the user.
Access-Reject: The RADIUS server uses these packets to notify the NAS that the information provided via the
request is not acceptable.
Access-Challenge: The RADIUS server uses these packets to send the user a challenge requiring a response to obtain
additional information.
Accounting-Request: The NAS sends these packets to deliver information about the user session for accounting
purposes.
Accounting-Response: These packets help the RADIUS server notify the NAS that the Accounting-Request has been
received and processed successfully.
259
||||||||||||||||||||
||||||||||||||||||||
RADIUS Attribute-Value Pairs (AVP) are used to exchange information between the NAS and the authentication server to
support the AAA process. They provide useful information about the access request being made, as well as a way for the
authentication server to inform the NAS about the different parameters that need to be enforced.
These containers of information include a type, a length, and a value that defines them. Because the type field is an octet,
up to 255 attributes can be used; some of them are already predefined and well known. One of these attributes, Vendor-
Specific Attribute (attribute 26), enables vendors to communicate vendor-specific information by encapsulating their own
extended attributes inside it, as illustrated in Figure 5-7.
CoA
In a standard RADIUS session, the NAS is required to initiate the exchange and does not support unsolicited messages. To
provide more flexibility, the IETF RFC 5176 informational document defines enhancements that allow the authentication
server to dynamically modify the authorization of a user session via Change-of-Authorization (CoA) messages.
CoA messages sent by the CoA client (RADIUS server) are transported over UDP using 3799 as the destination port.
(Cisco implementation uses port 1700.) The NAS will reply with a CoA Acknowledgment (CoA-ACK) if it can
successfully change the authorization for the user session, or a CoA Non-Acknowledgement (CoA-NAK) if the request is
unsuccessful.
To target a CoA request to a particular session, the RADIUS server includes one or more of the following attributes:
Acct-Session-Id (IETF attribute 44)
Audit-Session-Id (Cisco vendor-specific attribute)
Calling-Station-Id (IETF attribute 31, which contains the host MAC address)
AAA Sequence
Now that we have covered the protocols that are used during the AAA process, let’s examine at a high level the
operational sequence displayed in Figure 5-8, which shows how the components and protocols of 802.1X work together.
260
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
262
Technet24
||||||||||||||||||||
||||||||||||||||||||
The CISCO ISE communication model shows the user PAN logging into the MnT to view logs and reports. The
PAN and PSN are bi-directionally connected to each other to view and configure policies. The PSN is also login to
the MnT. The PSN and external identity source is bi-directionally connected to each other by query attributes. The
PSN and NAD are bi-directionally connected to each other for request or response context. The NAD is also login
to the MnT. The NAD and endpoint are bi-directionally connected to each other by the access request. The NAD
and resource are bi-directionally connected to each other by resource access.
Note
For the latest deployment size and scaling recommendations, refer to the most recent release of the Cisco Identity Services
Engine Installation Guide at https://www.cisco.com/c/en/us/support/security/identity-services-engine/products-
installation-guides-list.html.
To edit the current personas and services assigned to a specific node, navigate to Administration > System >
Deployment. From there, click the name (or check the check box next to the node you want to change and click Edit) to
bring up the screen similar to the one shown in Figure 5-10 that will enable you to make the changes for the node.
263
||||||||||||||||||||
||||||||||||||||||||
The deployment option under the system tab from the administration menu got selected. This displays the edit
node page that includes options like general settings and profiling configuration. In which, the general settings
shows hostname, FQDN, IP address, and node type that reads Identity Services Engine (ISE), administration,
monitoring, policy service that includes enable session services, enable profiling service, enable threat centric
NAC service, enable SXP service, enable device admin service, enable passive identity service, and pxGrid. Here
the administration option includes role option, which is set to STANDALONE.
If you’re working on a distributed deployment, the first step is to promote the node from Standalone to Primary to be
allowed to add any additional nodes. After the role is changed, you can go back and click Register to start the process of
adding nodes by providing the required information as displayed in Figure 5-11. Keep in mind that the PAN will need to
validate the certificates of the nodes that will be added, so before starting the registration process make sure that you have
completed all the certificate provisioning tasks.
264
Technet24
||||||||||||||||||||
||||||||||||||||||||
ISE Certificates
The Cisco ISE relies on a Public Key Infrastructure (PKI) to be able to perform authentication and to secure
communications. There are two types of certificates in ISE:
System certificates: These certificates enable ISE to be identified and authenticated by other entities. Each node in
the deployment holds its own system certificates, and by default they have a self-signed certificate that is created
during installation. System certificates can be used for the following:
Admin: To authenticate the ISE Admin portal and secure inter-node communication.
EAP: For EAP authentication that uses SSL/TLS tunneling.
RADIUS DTLS: For RADIUS DTLS authentication (RADSec).
Portal: For securing communication with ISE portals.
pxGrid: For communicating with the pxGRID controller.
Trusted certificates: These certificates enable ISE to validate and authenticate the certificates received from users,
devices, and other ISE nodes.
Certificates can be centrally managed via the Admin node. Three high-level steps must be completed to deploy certificates
on ISE:
Step 1. Create a Certificate Signing Request (CSR) by navigating to Administration > System > Certificates >
Certificate Signing Requests and entering the required values for the different certificate fields, as shown in Figure 5-12.
You can generate a request per each ISE node, or alternatively you can request a wildcard certificate (a certificate that
uses a * character in the left-most section of the Common Name or Subject Alternative Name) that would enable you to
share it across multiple nodes. After the CSR is generated, it must be submitted and digitally signed by a certificate
authority.
265
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Cisco ISE provides network access services using a policy-based approach. Policies are built using rules that contain
conditions. Cisco ISE will evaluate sequentially the rules within the policy, and if the conditions are satisfied it will apply
the configured result actions.
Authentication Policy
Authentication policies define the rules that will be used to determine how to authenticate users and endpoints. These rules
dictate what protocols will be allowed and what identity sources will be used for authentication. A rule-based
authentication policy flow is represented in Figure 5-15.
267
||||||||||||||||||||
||||||||||||||||||||
The Authentication Rule #1 flow starts with the decision that reads, Rule conditions met? If Yes, it leads to
Allowed Protocols and RADIUS Proxy and if No, it leads to Authentication Rule #n which further leads to Default
Authentication Rule, where the Allowed Protocols leads to the decision that reads, Identity rule met? of the
Identity Rule #1. If yes, it leads to Identity Source and if No, it leads to Identity Rule #n, which flows to Default.
The RADIUS Proxy and the Default Authentication Rule leads to a decision that reads, Authentication result?. If
PERMIT CONTINUE, it leads to Authorization Policy and if REJECT DROP, it leads to Deny Access.
During the evaluation of the policy, rules are processed from top to bottom. When the conditions of a rule are met,
processing stops, and the matching network access service and identity source are used.
You can configure the authentication policy by going to Policy > Authentication. This policy includes the elements
highlighted in Figure 5-16.
268
Technet24
||||||||||||||||||||
||||||||||||||||||||
The authentication tab under the policy menu got selected. This displays the authentication policy page that
includes elements like conditions, allowed protocols, failover options, and identity source. Here wireless_802.1X
indicates conditions, default network access indicates allowed protocols, All_user_ID_Stores indicates identity
source, and the options like if authentication failed (reject), if user not found (reject), and if process failed (drop)
indicates failover options.
Conditions: Determine the attributes that need to be matched to process a particular rule. There are simple conditions
that consist of a single attribute/operator/value set, and compound conditions that are made up of one or more simple
conditions tied with an AND/OR operator. When adding conditions to a rule, you will be able to select between
conditions from the existing library or create a new conditions, as shown in Figure 5-17.
269
||||||||||||||||||||
||||||||||||||||||||
The authentication tab under the policy menu got selected. This displays the authentication policy page that
shows conditions which includes select existing condition from the library and create new condition options.
In which, the select existing condition from library option shows a pop up that includes fields like condition
name, description, and compound condition with a search option to search conditions from the library whereas
the create new condition option shows a pop up that includes fields like condition name and description to
enter the details of the new condition.
Allowed protocols: Defines the protocols that ISE can use to communicate with endpoints requesting access to the
network. You can customize the protocols allowed by going to Policy > Policy Elements > Results > Authentication
> Allowed Protocol Services and creating a new service or leveraging the default network access service that is
predefined and shown in Figure 5-18.
270
Technet24
||||||||||||||||||||
||||||||||||||||||||
The allowed protocols services under the authentication of the results option, which is under the policy
elements tab from the policy menu got selected. This displays the allowed protocols page that includes fields
like name, description, and allowed protocols. The allowed protocols further include checkboxes for process
host lookup (selected), allow PAP/ASCII (selected), allow CHAP, allow MS-CHAPv1, allow MS-CHAPv2,
allow EAP-MD5 (selected), allow EAP-TLS (selected), allow LEAP, and allow PEAP (selected).
Identity Source: An identity source or an identity source sequence determines the user or endpoint repositories that
will be used for authentication. This can include internal or external sources. To configure identity sources, navigate to
Administration > Identity Management. Figure 5-19 shows a sample of external identity sources that could be
referenced within an authentication policy.
271
||||||||||||||||||||
||||||||||||||||||||
The certificate authentication profile under the external identity sources option, which is under the identity
management tab from the administration menu got selected. This displays the certificate authentication profile
page that includes menu like edit (hidden), add, duplicate (hidden), and delete (hidden) options, which shows
two checkboxes for name and preloaded_certfificate_profile with its description.
Failover Options: Define what action to take if authentication fails, if the user is not found, or if the process fails.
One of the main use cases when we use these failover option is to implement MAC Authentication Bypass (MAB): if
the MAC address is unknown, authentication can still succeed and the session will move to authorization. Note that the
option to continue if the user is unknown doesn’t work well with wireless dot1x: wireless dynamic encryption keys
won’t be able to be derived without the proper keying material.
After Cisco ISE concludes processing the authentication policy and the result is not an access reject, it moves to evaluate
the rules in the authorization policy.
Authorization Policy
The authorization service in Cisco ISE is defined via a rule-based policy that allows controlling user access to the network
and its resources. Within the authorization policy are two sets of rules that you can configure:
Standard: Meant to be used as the main set of rules for normal operation.
Exceptions: Intended to be used in the short term to meet a specific exception requirement.
Similar to authentication rules, authorization rules are processed from the top down. Exception rules, if defined, will be
processed first before moving to the standard rules. Additionally, ISE can be directed to use either the first matched rule or
to match and apply the results of multiple rules. The high-level authorization policy flow is shown in Figure 5-20.
272
Technet24
||||||||||||||||||||
||||||||||||||||||||
273
||||||||||||||||||||
||||||||||||||||||||
The authorization option under the policy menu got selected. This displays the authorization policy page which
contains a set of rules with the attributes like status, rule name, conditions, and permissions. Here, one of the
rules named Wi-fi_Employee_Access reads any and wireless_802.1X that indicates conditions and
permitAccess that indicates permissions.
274
Technet24
||||||||||||||||||||
||||||||||||||||||||
The authorization profiles under the results option, which is under the policy elements tab from the policy
menu got selected. This displays the authorization profile page which includes fields like name that reads
Cisco_WebAuth, description, access type that reads ACCESS_ACCEPT, network device profile, service
template, track movement, passive identity tracking. Further, it includes three sections namely common tasks,
advanced attribute settings, and attributes details where the common tasks show checkboxes for web
redirection (selected), display certificates renewal message, and static IP/hostname/FQDN.
Profiling Policy
Profiling in Cisco ISE is implemented via profiling policies and is a key service that helps identify, locate, and determine
the capabilities of endpoints that connect to the network. The profiling service is enabled by default on the PSNs along
with some of the basic probes (RADIUS, DHCP, NMAP) that are responsible for collecting the endpoint attributes. This
can be viewed or edited by going to Administration > System > Deployment and selecting the desired PSN.
To profile a device, Cisco ISE uses the various collected attributes for each endpoint and tries to determine the device type
by matching them to built-in or user-defined profiling policies that can be configured by going to Policy > Profiling. These
profiling policies, shown in Figure 5-23, contain one or more rules that if matched will increase the certainty factor; the
profile for which the endpoint has the highest cumulative factor is the one that will be assigned. The conditions that are
used in the rules are available by navigating to Policy > Policy Elements > Conditions > Profiling.
275
||||||||||||||||||||
||||||||||||||||||||
The profiling tab under the policy menu got selected. This displays the profiler policy page which includes fields
such as name, policy enabled, minimum certainty factor, exception action, network scan, associated CoA type. At
the bottom it includes rules which read if condition: AndroidRule1Check2 then: certainty factor increases, and if
condition: AndroidRule1Check1 then: certainty factor increases. Both the if conditions show the pop-up that
includes name, description, type, attribute name, operator, attribute value, system value, and system type fields.
Although different types of attributes are collected, the most common ones used for profiling clients are based on
RADIUS, MAC OUI, DHCP, and HTTP.
The profiling service plays an important supporting role for the authorization process. Authorization rules can leverage the
profiling policy applied to an endpoint as an additional condition to match. This can be done in two ways:
Creating a matching identity group, as shown in Figure 5-24, where endpoints will be placed after they are profiled.
276
Technet24
||||||||||||||||||||
||||||||||||||||||||
The profiling tab under the policy menu got selected. This displays the profiler policy page which includes
create an identity group for the policy field that shows two radio buttons namely yes, create matching identity
group and no, use existing identity group hierarchy. Here, the create matching identity group option shows a
pop up that contains the endpoint identity groups, where one of the groups named android points to a rule that
shows android_devices (rule name), If Android AND wireless_access (conditions), and then PermitAccess
(permissions). This indicates the endpoints will be placed after the matching identity groups are profiled.
Using logical profiles that act as containers for multiple profiling policies, as displayed in Figure 5-25.
277
||||||||||||||||||||
||||||||||||||||||||
Guest Access
Cisco ISE has the capability to provide guest access to users, such as visitors, contractors, and customers, by allowing them
to perform web authentication using a guest portal. Two main services cover the full life cycle of guest access: guest
services, which focus on the customizable portals and guest types, and sponsor services, which deal with sponsor portals
and sponsor groups.
Guest Services
Cisco ISE guest services allow hosting multiple customizable portals. Three types of portals, for which the high level flow
is shown in Figure 5-26, can be created:
Hotspot Guest Portal: Guests can access the network without requiring credentials, but you can add a welcome
message and an Acceptable Usage Policy (AUP).
Sponsored Guest Portal: The guest portal requires guests to have credentials to gain access. Sponsors will be
responsible for creating the guest accounts because guests cannot create their own accounts.
Self-Registered Guest Portal: Guests are allowed to provide information to automatically create their own account,
which they will use to log in to the portal. Having sponsor approval can be added as an optional requirement.
The guest portal types are classified as hotspot guest portal, sponsored guest portal, and self-registered guest
portal. In the hotspot guest portal, the AUP leads to Success. The sponsored guest portal flows downward as
follows: Login, AUP, Max Devices Reached, Post Login Banner, and Success. The Self-Registered guest
278
Technet24
||||||||||||||||||||
||||||||||||||||||||
The portal and components option under the guest access tab from the work centers menu got selected. This
displays the portal settings page which includes authentication method field that includes a drop-down set to
Guest_Portal_Sequence and the employees using this portal as guests inherit login options field that includes a
drop-down set to daily (default). The authentication method field shows a pop up that includes three sections
namely identity source sequence, certificate-based authentication, and authentication search list whereas the
employees using this portal as guests inherit login options field shows a pop up that includes guest type name,
description, collect additional data, maximum access time, login options, and account expiration notification fields.
Sponsor Services
The Cisco ISE sponsor portal enables you to create, edit, suspend, and reinstate guest user accounts. Configuration of the
sponsor portal is done through the Work Centers > Guest Access > Portals & Components > Sponsor Portals section.
To control access to the sponsor portal, different levels of sponsor responsibility can be added and assigned to internal
employees who create accounts for guests. These sponsor groups control the guest types that can be created by members
of the group, as well as which accounts they can view and edit. Access to sponsor groups is assigned by adding members,
which can be internal or external user groups. The configurable settings for a sponsor group are shown in Figure 5-28.
279
||||||||||||||||||||
||||||||||||||||||||
Active Directory (AD) is leveraged by most organizations as their main identity source. By allowing you to integrate AD
with ISE, objects such as groups and directory attributes become elements that can be used in the authorization policy
rules.
To integrate with Active Directory, on Cisco ISE navigate to Administration > Identity Management > External
Identity Sources > Active Directory. From there you need to add a new AD connection by specifying the domain name.
Then, each relevant Cisco ISE node must be selected to request the join process, as shown in Figure 5-29. It is not
mandatory to be a domain administrator to perform the join process; the account just needs to be able to search the
domain, create the machine accounts for the ISE nodes, and set their attributes.
280
Technet24
||||||||||||||||||||
||||||||||||||||||||
The active directory folder under the external identity sources option, which is under the identity management tab
from the administration menu got selected. The connection menu shows fields like joint point name that reads
wireless and active directory domain that reads wireless.local. The join domain pop up shows AD username,
password, specify organizational unit, and store credentials fields with ok and cancel buttons.
After you have joined the domain, you can retrieve and configure AD groups, making them available to be used as
additional attributes in conditions inside the authorization policy rules, as shown in Figure 5-30.
||||||||||||||||||||
||||||||||||||||||||
Cisco ISE can provide Device Administration services (TACACS+) allowing administrators to securely log in to network
devices to perform configuration and maintenance tasks.
One way to enable TACACS+ is to navigate to Work Centers > Device Administration > Overview > Deployment, and
from there select the nodes that will provide the service, as shown in Figure 5-31. The alternative method is to go to
Administration > System > Deployment, and from there select the desired PSNs and enable the Device Admin Service
under the General Settings for the node.
Technet24
||||||||||||||||||||
||||||||||||||||||||
Policy Sets
Policy sets are enabled by default for the Device Administration service. They act as hierarchical containers to logically
group the authentication and authorization policies. Each policy set will have conditions, as shown in Figure 5-33, that are
evaluated to determine whether there is a match. If the conditions are met, the authentication and authorization policies
283
||||||||||||||||||||
||||||||||||||||||||
Authentication Policy
Authentication policies follow the same logic as their counterpart for network access authentication. As shown in Figure 5-
34, they include rules that determine which protocols will be allowed and the identity source to use to validate the
credentials provided.
Authorization Policy
Although the authorization policy, such as the one displayed in Figure 5-35, follows the same common structure using rules
and conditions to determine the access that will be granted, there are two elements that are unique to the Device
Administration service:
Command Sets: Enforce a specific list of commands that can be executed by a device administrator (not used by
WLCs or Prime Infrastructure).
TACACS+ Profiles (Shell Profile): Control the session of the device administrator by sending back a set of attributes
that limits the actions that may be performed on the network device. To configure TACACS+ Profiles, navigate to
Work Centers > Device Administration > Policy Results > TACACS Profiles.
284
Technet24
||||||||||||||||||||
||||||||||||||||||||
The exceptions under the device administration authorization policy displays a tick mark to the following five
rule name WLC_RO, WLC_RW, PI_RO, PI_RW, and Tacacs_Default with its respective conditions,
command sets, and shell profiles. The shell profile of WLC_RW reads WLC ALL, this points to the window
WLC ALL of TACACS profile. The TACACS profile window shows the name and description to be entered;
followed by two views are shown, task attribute view (selected) and raw view. The common task section
displays a drop-down for common task type and the all radio button is selected.
Now that we have covered some of the basics, it is time to go through some of the most common wireless flows that can be
implemented using Cisco Identity Services Engine. This should serve as a foundation to build on and give you an idea of
how to later generate more advanced security policies.
Keep in mind that so many options and combinations exist that it will be hard to cover them all in this chapter. We will
focus on the base configuration that is critical for making things work. Additionally, several components are preconfigured
to simplify the initial deployment process that we will highlight where relevant.
Common Configuration
One of the first things that needs to be configured is to enable communication between the WLC and Cisco ISE. This must
be completed on both sides.
To configure ISE, go to Administration > Network Resources > Network Devices and add the WLC as a new network
device. The name and IP address, and enabling RADIUS and TACACS+ with a shared secret is the minimum configuration
to be entered, as depicted in Figure 5-36. Optionally, other attributes, such as Network Device Group membership (that is,
Device Type or Location), although not mandatory, could become useful in building more complex conditions in the
different types of policies.
285
||||||||||||||||||||
||||||||||||||||||||
286
Technet24
||||||||||||||||||||
||||||||||||||||||||
287
||||||||||||||||||||
||||||||||||||||||||
The WLC RADIUS fallback mode is shown by the Security menu, selected from the top horizontal menu
options. The left pane reads the navigations. The fallback is selected by expanding the AAA and then the
RADIUS option on the left pane. The right pane displays the navigation at the top, fallback parameters is
selected from RADIUS. The fallback mode drop-down box selects active; the username field is entered as
probe-user, and the interval in seconds field is entered as 300.
By default, RADIUS Aggressive Failover is enabled, which causes the WLC to flag the server as not responding if it
fails to get a response back for a single client (which could be due to the server doing a silent discard). By disabling
this setting, the WLC will failover to the next server only if there are three consecutive clients that fail to receive a
response from the RADIUS server. This change can be performed only via the CLI with the config radius aggressive-
failover disable command.
On a WLAN, the Session Timeout by default is 1800 seconds, which is the interval before client reauthentication is
enforced. This short interval could create an unnecessary load on the ISE server, so it is recommended, depending on
the deployment requirements, to consider changing this timer to at least 7200 seconds, as shown in Figure 5-39.
288
Technet24
||||||||||||||||||||
||||||||||||||||||||
Attributes Values
---------- ------
User-Name testuser
Called-Station-Id 00-00-00-00-00-00:8021Xssid
Calling-Station-Id 00-11-22-33-44-55
Nas-Port 0x00000001 (1)
Nas-Ip-Address 100.127.100.10
NAS-Identifier 0x574c4331 (1464615729)
Airespace / WLAN-Identifier 0x00000001 (1)
User-Password testpwd
Service-Type 0x00000008 (8)
Framed-MTU 0x00000514 (1300)
Nas-Port-Type 0x00000013 (19)
Tunnel-Type 0x0000000d (13)
Tunnel-Medium-Type 0x00000006 (6)
Tunnel-Group-Id 0x00000064 (100)
Cisco / Audit-Session-Id 647f640a000000175b7debc8
Acct-Session-Id 5b7debc8/00:11:22:33:44:55/1271
test radius auth request successfully sent. Execute 'test aaa show radius' for
response
||||||||||||||||||||
||||||||||||||||||||
Authentication Response:
Result Code: Success
Attributes Values
---------- ------
User-Name testuser
State ReauthSession:647f640a000000175b7debc8
Class CACS:647f640a000000175b7debc8:ise/323248099/95
Tunnel-Type 0x0000000d (13)
Tunnel-Medium-Type 0x00000006 (6)
Tunnel-Group-Id 0x000000c8 (200)
In a wireless network, specific RADIUS attributes can be used to exchange information between the WLC and ISE in
regard to the users or endpoints that are trying to gain access. In addition to this section or the configuration guides, one
good place to review these attributes is to go to Policy > Policy Elements > Dictionaries in ISE.
Table 5-1 identifies a subset of the most common RADIUS attributes that are sent by the WLC to ISE as part of the
access-requests. These attributes would be used to help build our compound conditions for rules in the authentication and
authorization policies.
Table 5-1 Authentication Attributes Sent in Access-Request Packets
User- Example:
IETF 1
Name Radius:NAS-IP-Address CONTAINS DomainName
This condition can match on request from users for which their username is part of a
specific domain.
This attribute indicates the IP address of the WLC that is requesting authentication of the
user.
NAS-IP- Example:
4
Address
Radius:NAS-IP-Address EQUALS 100.127.100.10
This condition can be used to match by IP address requests coming from specific WLCs
Indicates the type of service the user has requested. The values used typically by the
WLC are the following:
Login (1): Used for local web authentication
Framed (2): Used when performing 802.1X
Service- 290
Technet24
||||||||||||||||||||
||||||||||||||||||||
This attribute will normally store the AP MAC address appending the SSID (<xx-xx-xx-
xx-xx-xx>:<ssid>). The behavior can be modified via configuration on the WLC.
Called- Example:
30
Station-ID
Radius:Called-Station-ID ENDS WITH ssid1
This condition will match on request of users connecting to and specific SSID.
Calling-
31 This attribute contains the MAC address of the client.
Station-ID
This attribute contains a string identifying the WLC originating the Access-Request,
typically being the WLC hostname. The value can be modified at the AP Group or
WLAN level.
NAS-
32
Identifier Example:
Radius:NAS-Identifier EQUALS WLC1
This condition can be used to match by hostname request coming from specific WLCs.
Indicates the type of the physical port of the NAS authenticating the user. For a WLC this
value will always be Wireless - IEEE 802.11 (19).
NAS-Port- Example:
61
Type
Radius:NAS-Port-Type EQUALS Wireless - IEEE 802.11
This condition will match on request initiated by a WLC.
Every WLAN created on the WLC has a numeric WLAN ID. This attribute sends the ID
value matching the WLAN that the client is connecting to.
Example:
Airespace-
Airespace 1
Wlan-Id Airespace:Airespace-Wlan-Id EQUALS 2
This condition will match on request for users connecting to a specific WLAN. One
disadvantage to this attribute is if the WLAN ID does not match on an SSID spread across
multiple controllers.
In Figure 5-40 we can see an example of how we can use a combination of these attributes to hone in to a particular access
request. In this particular case it would be for wireless users connecting using 802.1X to SSID1.
291
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Figure 5-41 shows how we can leverage the attributes listed previously to configure authorization profiles that will send
this value to the requesting NAS device. In this example the authorization profile will send back a URL to redirect the user
and an ALC to trigger the redirect and limit the access that the user will be given.
The authorization profile leveraging the additional attributes shows the menu 'Policy,' selected from the menus at
the top; the sub-menu, Policy elements (drop-down) tab is selected. The result is selected from the left pane. The
authorization profile is selected by expanding the Authorization options. The right pane displays the navigation at
the top, 'Blackhole_Wireless_Access is selected from authorization profiles. The name (mandatory field) reads
Blackhole_Wireless_Access, and the description box reads Default profile used to blacklist wireless devices.
294
Technet24
||||||||||||||||||||
||||||||||||||||||||
802.1X
Unarguably, 802.1X is the preferred method for securing wireless network access, with PEAP and EAP-TLS being the
EAP methods more widely deployed. Most large organizations will also tend to use Active Directory as the back-end
identity repository where employee accounts reside.
The steps required to implement this scenario on the WLC are fairly simple. In addition to the common configuration
previously discussed, a new WLAN needs to be created with the following parameters that are also shown in Figure 5-42:
Layer 2 Security should be set to WPA2 with AES Encryption and using 802.1X for authentication key management.
Optionally, FT 802.1X can be enabled if implementing 802.11r.
AAA Servers can optionally be configured if you want to override the order of the global RADIUS servers list.
For the Advanced settings, it is recommended to enable AAA Override to allow ISE to send attribute-value pairs to
dynamically override any existing client policy that was statically assigned via the WLAN configuration. Additionally,
NAC state should be configured as ISE NAC to allow ISE to send CoA requests.
The WLAN 802.1 X WLAN setting is shown by the W LANs menu, selected from the top horizontal menu
options. The left pane reads the navigations. The right pane displays the navigation at the top, Edit dot1X is
295
||||||||||||||||||||
||||||||||||||||||||
The authentication policy of 802.1X shows the Policy tab selected from the menu at the top; and the sub-menu
authentication is selected. The Authentication policy in the content pane displays the text, for policy export
navigate to the link Administration, system, backup and restore, and policy export page. The radio button for
policy type shows simple and rule-based (selected). The policy for four checkboxes Wireless_Dot1X,
Wireless_EAP-TLS, Wireless_PEAP, and Default are selected and details are shown.
The authentication rule is configured with the Wireless_802.1X compound condition that is predefined in the library. This
condition matches on wireless 802.1X-based authentication requests from the WLC by evaluating the AVPs using these
expressions:
Radius:Service-Type Equals Framed (2)
Radius:NAS-Port-Type Equals Wireless—IEEE 802.11 (19)
In Example 5-2, we can see from the debug output on the WLC that the authentication request being sent for an 802.1X
client includes AVPs (12 and 14 in this case) with values that match the Wireless_802.1X compound condition in ISE.
Example 5-2 debug aaa events enable—802.1X Authentication Request
Click here to view code image
*aaaQueueReader: Aug 24 22:42:32.259: AuthenticationRequest: 0xffebe69ce8
*aaaQueueReader: Aug 24 22:42:32.259:
Callback.....................................0x1079c450
*aaaQueueReader: Aug 24 22:42:32.259:
protocolType.................................0x00140001
*aaaQueueReader: Aug 24 22:42:32.259:
proxyState...................................68:7F:74:FC:8C:0F-02:00
*aaaQueueReader: Aug 24 22:42:32.259: Packet contains 19 AVPs:
*aaaQueueReader: Aug 24 22:42:32.259: AVP[01] User-
[email protected] (20 bytes)
*aaaQueueReader: Aug 24 22:42:32.259: AVP[02] Chargeable-User-
296
Technet24
||||||||||||||||||||
||||||||||||||||||||
297
||||||||||||||||||||
||||||||||||||||||||
298
Technet24
||||||||||||||||||||
||||||||||||||||||||
The certificate authentication profile selects the Administration tab from the menu at the top; and the sub-
menu Identity management is selected. The external identity source is selected from the left pane. The
preloaded_certificate_profile is selected by expanding the certificate authentication profiles file on the left
pane. The right pane displays the name (mandatory field) reads preloaded_certificate_profile, and the
description box reads Precreated certificate authorization profile. The identity store drop-down is selected as
not applicable. The certificate attribute radio button is selected for the use identity from. Never radio button is
selected for the Match client certificate against certificate in identity store.
PEAP, on the other hand, will use Active Directory (join point named AD_WIRELESS) to validate the credentials.
After we conclude the authentication process, ISE will move to evaluating the authorization policy. In the example
represented in Figure 5-46, we have two authorization rules to show how to provide different network access to users.
299
||||||||||||||||||||
||||||||||||||||||||
The authorization policy of 802.1X shows the Policy tab selected from the menu at the top; and the sub-menu
authorization is selected. The authorization policy in the content pane displays the text, define the authorization
policy by configuring rules based on identity groups and/or other conditions. For policy export navigate to the link
Administration, system, backup and restore, and policy export page. The first matched rule applies drop-down is
selected. Under Exceptions, the standard three checkboxes Wireless_EAP-TLS, Wireless_PEAP, and Default are
checked and its conditions and permissions are displayed.
The first rule looks for wireless users (leveraging the Wireless_802.1X previously described) using EAP-TLS. This is a
typical use case for internal users that have been provisioned with a valid certificate (such as employees). If meeting
the criteria of the conditions for this rule, ISE will assign the EAP-TLS_user authorization profile that is shown in
Figure 5-47 and that is configured to override the VLAN assigned by the WLC to the user.
300
Technet24
||||||||||||||||||||
||||||||||||||||||||
Under the authorization profiles, the name (mandatory field) is entered as E A P T L S_user, and the
description box is entered as Sample authorization profile for E A P T L S_users. The access type
(mandatory) drop-down is set to ACCESS_ACCEPT. The network device profile drop-down selects CISCO
with its logo; three checkboxes, service templates, track movement, and passive identity tracking are
unchecked. The common tasks section includes three checkboxes VLAN (checked) with Tag ID 1, an Edit tag
button and ID/Name 200; the ACL and voice domain permission checkboxes are unchecked. The Advanced
attributes settings show a pair of drop-down that equals each other. A decrement and increment buttons are
placed to its right. The attributes details are shown at the bottom.
As we look in Example 5-3, the Access-Accept received by the WLC, we can see the attributes that match those
301
||||||||||||||||||||
||||||||||||||||||||
The second rule not only looks for wireless users using PEAP but also checks whether they belong to the right Active
Directory user group. This use case is common in certain BYOD scenarios or when giving access to contractors or
other users that have valid AD accounts. Matching this rule will assign the PEAP_user authorization profile as shown
in Figure 5-48, for which ISE will send back the ACL name that the WLC will need to apply to the user session.
302
Technet24
||||||||||||||||||||
||||||||||||||||||||
The authorization profiles for PEAP users shows the navigation PEAP_user, selected from the authorization
profiles. The name (mandatory field) is entered as PEAP_user, and the description box is entered as Sample
authorization profile for PEAP users. The access type (mandatory) drop-down is set to ACCESS_ACCEPT.
The network device profile drop-down selects CISCO with its logo; three checkboxes, service templates, track
movement, and passive identity tracking are unchecked. The common tasks section includes four checkboxes
Airespace ACL name (checked) with a field reads ACL_Restricted; the web authentication, ASS VPN, and
303
||||||||||||||||||||
||||||||||||||||||||
MAC Filtering, and its variation MAC Authentication Bypass, would typically be configured on an open or PSK WLAN
and allows the use of the MAC address of an endpoint to determine what type of network access to provide, depending on
whether it is a known or unknown device.
Configuration on the WLC requires creating a WLAN with the following settings that are also represented in Figure 5-49:
Layer 2 Security can either be none (open) or using WPA2 with AES Encryption and PSK for authentication key
management. MAC filtering needs to be enabled.
AAA Servers and Advanced settings should be configured following the same guidelines mentioned on the 802.1X
304
Technet24
||||||||||||||||||||
||||||||||||||||||||
The MAB WLAN setting is shown by the WLANs menu, selected from the top horizontal menu options. The
left pane reads the navigation WLANs selected from the WLANs option. The right pane displays the
navigation at the top; the security tab is selected from the five given tabs; the Layer 2 subtab is selected from
the three given subtabs. In the content pane, the Layer 2 security reads WPA+WPA2 from the drop-down,
and the checkbox MAC Filtering is selected and highlighted.
The Authentication Policy on ISE would need to have a rule configured, such as the one shown in Figure 5-50.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
The MAB authorization policy shows the Policy tab selected from the menu at the top; and the sub-menu
authorization is selected. The authorization policy in the content pane displays the text, define the
authorization policy by configuring rules based on identity groups and/or other conditions. For policy export
navigate to the link Administration, system, backup and restore, and policy export page. The first matched rule
applies drop-down is selected. Under Exceptions, the standard three checkboxes Wireless_MAB_Registered,
Wireless_MAB_Unknown, and Default are checked and its conditions and permissions are shown.
Web authentication (WebAuth) is a Layer 3 security mechanism that allows users, typically guests, to easily gain access to
the network by providing credentials through a web browser.
Two deployment modes are available for WebAuth with ISE: Local Web Authentication (LWA) and Central Web
Authentication (CWA). Although Cisco recommends the use of CWA with ISE, there are some scenarios where LWA is
preferred due to its simplicity or because it is the only viable option for the network environment.
In LWA, the WLC is “locally” configured to redirect the user to the web authentication portal and will be responsible for
receiving the user credentials that need to be submitted to ISE for authentication.
When a user connects to a WLAN configured for LWA, it will go through the flow shown in Figure 5-52.
1. The user will connect to an open (although less common, PSK security is also supported) SSID that is configured for
WebAuth.
307
||||||||||||||||||||
||||||||||||||||||||
The MAB authorization policy shows the Policy tab selected from the menu at the top; and the sub-menu
authorization is selected. The authorization policy in the content pane displays the text, define the
authorization policy by configuring rules based on identity groups and/or other conditions. For policy export
navigate to the link Administration, system, backup and restore, and policy export page. The first matched rule
applies drop-down is selected. Under Exceptions, the standard three checkboxes Wireless_MAB_Registered,
Wireless_MAB_Unknown, and Default are checked and its conditions and permissions are shown.
Configuration of LWA on the WLC will typically start by defining the preauthentication ACL as the one shown in Figure
5-53. This ACL will be used to provide limited network access and trigger the redirection process. Here are a couple of
308
Technet24
||||||||||||||||||||
||||||||||||||||||||
The pre-authentication ACL defined for LWA configuration shows the Security menu selected from the top
horizontal menu options. The left pane displays various options with navigations. The general is selected by
expanding the AAA option on the left pane. On the right pane, the Edit is selected from the access control list.
The general tab in content pane shows the values for access list name and deny counters. The table below
reads the column headers, sequence, action, source IP/mask, destination IP/mask, protocol, source port,
destination port, DSCP, direction, and number of hits in table wise data.
As it relates to the WLAN, the following settings need to be configured:
Layer 2 Security will typically be none (open) to provide a simpler user experience; however, if needed, it can be
implemented with PSK as well.
The Layer 3 Security policy will need to be configured for web authentication, as shown in Figure 5-54. The
preauthentication ACL previously created will need to be added to allow access to the WebAuth portal (this is not
required if using the WLC internal portal).
309
||||||||||||||||||||
||||||||||||||||||||
The WLAN settings of LWA layer 3 is shown from the WLANs menu, selected from the top horizontal menu
options. The left pane reads the navigation WLANs selected by expanding the WLANs. The right pane
displays the navigation at the top, Edit LWA selected from WLANs. The security tab is selected from the five
given tabs; the Layer 3 sub-tab is selected from the three given subtabs. In the content pane, from the drop-
down, the Web Policy is selected for the Layer 3 security; the authentication radio button is selected. From
the drop-down, the ACL_Redirect is selected for the IPv4 pre-authentication ACL. The enable checkbox is
selected for the over-ride global config. From the drop-down, the external (redirect to external server) is
selected for the Web Auth type and the portal URL is entered in the URL field. All the above are highlighted.
Finally, if using an external portal, the URL to redirect the user will need to be specified (can be also configured
globally). To find out the correct URL for the portal in ISE, navigate to Work Centers > Guest Access > Portal and
Components > Guest Portals Configure and select the specific portal that will be used. From there you can right-
click the link Portal Test URL, as shown in Figure 5-55, and choose Copy Link Location.
The LWA portal URL window shows the work centers selected from the menu at the top; the submenu guest
access is selected; and the tab portals and components are selected. The guest portal of the left pane shows the
portals settings and customization in the right pane. The field for portal name and description are entered; and
at the end of the description field, the link Portal test URL is highlighted.
Note
310
Technet24
||||||||||||||||||||
||||||||||||||||||||
311
||||||||||||||||||||
||||||||||||||||||||
312
Technet24
||||||||||||||||||||
||||||||||||||||||||
313
||||||||||||||||||||
||||||||||||||||||||
Guest services using Central Web Authentication (CWA) would be the preferred deployment model due to the flexibility it
provides. It builds on top of MAB, and it can provide additional capabilities that go beyond guest network access.
In CWA, the configuration for redirecting the user, the web authentication portal and the responsibility of directly
processing the user credentials, resides “centrally” in ISE. When a user connects to a CWA-enabled network, it will go
through the flow shown in Figure 5-59.
1. The user will connect to an open SSID. Transparent to the user, the WLAN is configured to perform MAC
authentication.
2. The WLC handles the MAC authentication process and sends the request to ISE.
3. ISE is configured to perform MAB and will send back to the WLC the redirection attributes.
4. The user acquires an IP address and will open a browser trying to fetch a web page (on modern operating systems, a
pop-up might even show up when the system detected the portal page automatically by sending HTTP test probes). At
this point the WLC will intercept the HTTP request and redirect the user to the WebAuth page that resides on ISE.
5. The user is presented with the guest login page where it will enter the username and password. These credentials get
submitted directly to ISE through the portal.
6. ISE will authenticate the user, and if successful, it will send a CoA back to the WLC.
7. When the user reconnects, the WLC will start the MAC authentication process all over again, but this time ISE is
aware that the user has authenticated, and it will grant it access to the network, possibly returning specific
authorization attributes such as an ACL.
314
Technet24
||||||||||||||||||||
||||||||||||||||||||
The central web authentication displays the User laptop is connected wirelessly to the AP/WLCs WLAN
controller and access point followed by a file server DHCP, DNS is placed and finally the ISE. Step 1 shows
the user open SSID with Macauth to the AP/WLC. Step 2 shows the user sends the first authentication session
to the ISE. Step 3 shows the ISE respond to the user by authentication success, authorization for MAB
returned with ACL and URL. Step 4 shows the request and response of DHCP DNS and user that, the user
acquires IP Address, moves to WebAuth state. Step 5 shows the user opens the browser, WLC redirects user
to ISE CWA page, then login into the page by and sending the credentials to the ISE. Step 6 shows the
WebAuth success results in CoA and the final step, step 7 shows the user sends MAC reauthentication to the
ISE and ISE respond the ISE server and the return policy.
Because this flow builds on top of MAB, the WLAN configuration on the WLC will be the same as previously reviewed in
the MAB section. In this scenario, however, make sure that AAA Override and ISE NAC are enabled as shown in Figure
5-60.
315
||||||||||||||||||||
||||||||||||||||||||
316
Technet24
||||||||||||||||||||
||||||||||||||||||||
The ACL defined for CWA configuration shows the Security menu selected from the top horizontal menu
options. The left pane displays various options with navigations. The general option is selected by expanding
the A A A option on the left pane. The right pane displays the navigation at the top, Edit is selected from the
access control list. The general tab in content pane shows the values for access list name and deny counters.
The table below reads the column headers, sequence, action, source IP/mask, destination IP/mask, protocol,
source port, destination port, DSCP, direction, and number of hits in table wise data.
On ISE, the Authentication Policy will leverage the MAB rule previously discussed. It is worth highlighting again the
importance of making sure that the If User Not Found option for the identity source is changed to Continue, as shown in
Figure 5-62. Users just initiating the CWA flow will not be known by ISE, but they will still need to move to the
authorization policy to get the redirect URL and ACL applied to their session.
317
||||||||||||||||||||
||||||||||||||||||||
318
Technet24
||||||||||||||||||||
||||||||||||||||||||
319
||||||||||||||||||||
||||||||||||||||||||
320
Technet24
||||||||||||||||||||
||||||||||||||||||||
321
||||||||||||||||||||
||||||||||||||||||||
The CWA live logs are shown by the operations menu, selected from the top horizontal menu options; the sub-
menu RADIUS and the tab Live logs are selected. The value for misconfigured supplicants, misconfigured network
devices, RADIUS drops, client stopped responding, and repeat counter is displayed. The live logs are displayed in
a table wise data having column headers, time, status, details, repeat, identity, endpoint ID, authentication policy,
authorization policy, and authorization profiles.
After the user enters his or her credentials in the web portal, ISE will issue a CoA to the WLC to modify the previous state
achieved after the first MAB process. The message received by the WLC from ISE can been seen in Example 5-8, and
because it is an unsolicited request, it contains attributes to identify the client whose status needs to be changed.
Example 5-8 debug aaa events enable—CoA
Click here to view code image
*radiusCoASupportTransportThread: Aug 29 19:52:43.858: Received a 'CoA-Request' from
192.168.100.6 port 62926
*radiusCoASupportTransportThread: Aug 29 19:52:43.858: Packet contains 9 AVPs:
*radiusCoASupportTransportThread: Aug 29 19:52:43.858: AVP[01] Nas-Ip-Address..
.........................0x647f640a (1686070282) (4 bytes)
*radiusCoASupportTransportThread: Aug 29 19:52:43.858: AVP[02] Calling-Station-
Id.......................68-7f-74-fc-8c-0f (17 bytes)
*radiusCoASupportTransportThread: Aug 29 19:52:43.858: AVP[03] Acct-Event-
Time..........................0x5b873ffe (1535590398) (4 bytes)
*radiusCoASupportTransportThread: Aug 29 19:52:43.858: AVP[04] Message-
Authenticator....................DATA (16 bytes)
*radiusCoASupportTransportThread: Aug 29 19:52:43.858: AVP[05] Message-
Authenticator....................DATA (16 bytes)
*radiusCoASupportTransportThread: Aug 29 19:52:43.858: AVP[06] Unknown
Attribute 0......................NULL (0 bytes)
*radiusCoASupportTransportThread: Aug 29 19:52:43.858: AVP[07] Unknown
Attribute 0......................NULL (0 bytes)
*radiusCoASupportTransportThread: Aug 29 19:52:43.858: AVP[08] Unknown
Attribute 0......................NULL (0 bytes)
*radiusCoASupportTransportThread: Aug 29 19:52:43.858: AVP[09] Unknown
322
Technet24
||||||||||||||||||||
||||||||||||||||||||
Profiling
The WLC is enabled with device profiler capabilities that allow it to collect client information that can be sent to ISE via
RADIUS accounting messages. Based on this information, administrators can then apply a policy to the device after its
type is known.
The WLC acts as the collector for two types of packets:
DHCP: The WLC receives a copy of the DHCP_REQUEST packet and parses the information to obtain the
HostName (Option 12) and the Vendor Class Identifier (Option 60). This information is then conveyed to ISE via the
cisco-av-pair: dhcp-option=<DHCP option> RADIUS Vendor Specific Attribute.
HTTP: The first HTTP packet sent from the client will be detected, and the WLC will use the user-agent attribute
from the HTTP header. This information will then be sent to ISE via the cisco-av-pair: http-tlv=User-Agent=<user-
agent> attribute.
To configure this feature, go to WLANs, click the target WLAN ID, go to the Advanced tab, and from there check both
DHCP and HTTP profiling under the Radius Client Profiling section, as shown in Figure 5-67.
323
||||||||||||||||||||
||||||||||||||||||||
324
Technet24
||||||||||||||||||||
||||||||||||||||||||
The Apple iPhone profiling policy is shown by the policy menu selected from the top horizontal menu options; and
the sub-menu profiling is selected. The left pane displays the set of devices android, apple, etc. The Apple iPhone
under the apple device is selected. The right pane shows the navigation at the top, Apple iPhone selected from the
profiler policy list. Under the section profiler policy (all fields are mandatory), the name Apple iPhone is entered in
the field, the checkbox policy enable is selected, the radio button, yes, create matching identity is selected for
identity group for the policy. Under Rules section, the field for If condition reads, Apple-iPhoneRule2Check1 and
Apple-iPhoneRule1Check1. Pointing to both the rule 1 and rule 2, two separate snippets are displayed for the
profiler condition list. Both include the name, description, type, attribute name, operator, attribute value, and
system type. The attribute name of rule 2 and rule 1 shows hostname and user-agent respectively.
325
||||||||||||||||||||
||||||||||||||||||||
We can use the Device Administration service in ISE to authenticate administrators wanting to gain management access to
WLCs and Cisco Prime Infrastructure.
The first step is to navigate to Work Centers > Device Administration > Network Resources to add the WLCs and PI as
network devices in ISE providing the TACACS+ settings, as shown in Figure 5-70. It’s important to note that each type of
platform requires different attributes back from ISE when performing authentication; thus it is recommended to group
devices together at minimum by type. (In this example we would use two: WLCs and Prime Infrastructure [PI].)
326
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
The WLCs TACACS plus profile shows the main menu work centers, selected from the menus at the top; the
sub-menu device administration is selected; and below, the tab policy elements is selected. The TACACS
profile is selected by expanding the results in the left pane. The right pane shows the navigation at the top,
WLC ALL selected from the TACACS profiles. It includes two sections TACACS profile and common tasks.
The TACACS profile shows the name and description that are to be entered; followed by two views are
shown, task attribute view (selected) and raw view. The common task section displays a drop-down for
common task type and the all radio button is selected.
PI uses the concept of role and task attributes that are specific per user group. These attributes, which are available on
PI at Administration > Users > Users, Roles & AAA > User Groups would need to be exported and imported into
the TACACS Profiles within ISE, as shown in Figure 5-72.
328
Technet24
||||||||||||||||||||
||||||||||||||||||||
The PI TACACS plus profile shows the main menu work centers selected from the menus at the top; the sub-
menu device administration is selected; and below, the tab policy elements is selected. The TACACS profile is
selected by expanding the results in the left pane. The right pane shows the navigation at the top, PI root
selected from the TACACS profiles. It includes two sections TACACS profile and profile attributes. The
TACACS profile shows the name and description that are to be entered; followed by two views are shown,
task attribute view and raw view (selected). The profile attributes section displays a list of tasks with its
attributes. This task area points to a CISCO prime infrastructure window that has a title
administration/users/users, roles and AAA. The left pane of this window selects the option user groups and its
respective tasks lists are given on the right pane of it.
At this point we can start creating our Device Admin Policy like the one shown in Figure 5-73. By default, Policy Sets are
enabled to allow organizing policies more easily. In this example the policy set Wireless will be used for devices belonging
to the WLCs or PI device groups, as defined by the policy set rules. Inside this set, we can see that authentication is
configured to use Active Directory exclusively (it could have been any of the supported identity sources). Finally, the
Authorization Policy is set up in a way that users belonging to Active Directory Group1 will have full access to both PI and
WLCs, and users belonging to Group2 will have only monitoring access to the WLCs.
329
||||||||||||||||||||
||||||||||||||||||||
The wireless admin policy shows the main menu 'work centers' selected from the menus at the top; the sub-menu
device administration is selected; and below, the tab device admin policy sets is selected. The content pane reads
the policy sets at the left pane that contains the summary of policies and global exceptions. The right pane shows
the wireless status with a tick mark followed by four sections, proxy server sequence, authentication policy,
authorization policy, and exceptions. The status of the default rule is ticked in authentication policy and the rule
name WLC ALL, WLC monitor, PI root, and Tacacs_default are ticked in standard section of exceptions.
Although this scenario was simple, the policies could be configured to leverage many more attributes in the rule conditions
to meet the security policy of the organization with regard to who gets access to manage the different infrastructure
devices.
Summary
Because the Cisco Identity Service Engine is such a flexible and feature-rich platform, trying to cover every little feature
and detail within the boundaries of a single section of book is impossible. As such, the purpose of this chapter was to
provide you with sufficient understanding of how things interact, common flows, and how policies get structured. Having
this base knowledge, along with sufficient hands-on practice, will allow you not only to increase your experience but to
also develop the creativity required to come up with solutions that meet different use case requirements that you might
encounter during your CCIE studies or as part of your day-to-day job responsibilities.
330
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figure 6-3 RADIUS and TACACS+ Custom Attributes for Virtual Domains
Putting authentication, group assignment, and virtual domains together, if you had to authorize users belonging to the group System Monitoring
and push the virtual domain Office1, the following would be an example of the two RADIUS attributes you would need to send back to Prime
Infrastructure in the final Access-Accept response:
Click here to view code image
cisco-av-pair = NCS:role0=System Monitoring
cisco-av-pair = NCS:virtual-domain1=Office1
Basic Operations
Although the features and operations described in the following paragraphs are introduced as “basic,” they still represent the foundation for
properly working with Cisco Prime Infrastructure. CCIE Wireless candidates may find them crucial to speed up workflows during the lab exam
too.
After having established how to manage administrative access to the management tool, one of the next steps is to use it for managing network
devices. In Prime Infrastructure, you can configure a WLC through pages with a similar look and feel as the WLC’s GUI. However, one of
Prime Infrastructure’s main advantages is to push multiple configuration changes at once to multiple WLCs; such a task can be achieved
through the configuration templates.
Prime Infrastructure communicates with the WLC through SNMP. A WLC can send SNMP traps to Prime Infrastructure, or NetFlow records
too for Application Visibility and Control (AVC) statistics. Even though Prime Infrastructure optionally asks for credentials to access a WLC via
telnet/SSH/HTTPS when adding the WLC to the list of managed devices, these credentials are not needed: all monitoring operations,
333
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Operating Maps
Another major interest of operating your Cisco wireless deployment through Prime Infrastructure is the additional visibility into your RF
environment, rogue APs, clients, and so on when using maps.
Fundamentally, a map is a floor plan where you can place your APs. In Prime Infrastructure’s internal hierarchy and configuration, a floor needs
to be part of a building, which can optionally be part of a campus. You do not need to import images for campuses and buildings, but you should
import background images for floor plans before starting to place APs. When configuring dimensions for campuses, buildings, and floors, the
default scale unit is in feet. You can change this to meters under the menu Maps > Wireless Maps > Site Maps ( New! ) by selecting your
campus and then the option Units of Measure through the Map Properties gear icon on the top right of the page.
Note
No matter whether you scale maps in Prime Infrastructure in feet or meters, when importing them in Cisco CMX (more on this in the next
sections) CMX will initially scale them in feet.
Among the final steps of a map creation, Prime Infrastructure asks you to launch the map editor to rescale the map with a ruler tool, define
obstacles, zones, GPS markers, and other properties. The following are best practices for most deployments: scaling maps is key for location
calculations in CMX, and although obstacles do not affect calculations for location services, they do improve the accuracy of RF heatmaps.
On top of obstacles, you might also want to add at least three GPS markers from the beginning, even before starting to place APs on the map.
These GPS coordinates are exported with the map properties when working with CMX and will be available in the CMX APIs. When
development teams retrieve GPS markers from a map and the client’s location coordinates on that map, they are therefore indirectly able to
calculate the GPS position of the client too.
After having configured all the necessary maps, placing and orienting APs may be considered one of the most boring and repetitive tasks in the
daily job of a wireless expert. Nevertheless, the precision and commitment you apply in such a task will determine the accuracy level of RF
predictions, clients’ location, rogue APs location, and so on. APs can be placed on a map only if they have registered to a WLC managed by
Cisco Prime Infrastructure at least once, even if for a short period of time, and even if the APs were taken offline right after the registration.
Prime Infrastructure needs to “see” them once. This can facilitate deployments where you need to send APs to site relatively quickly while
carrying on working proactively on their placement before the team on site installs them. You can, for example, register APs to your WLC in the
lab, or other prestaging facility, get them “seen” by Prime Infrastructure, and then unplug them to send them to site. While APs are on their way
to the final deployment site, you can keep working on their placements on the maps. Placing and orienting APs on maps does not affect any
configuration or Radio Resource Management (RRM) calculations on the WLC. An APs’ placement is used by Prime Infrastructure to predict
RF heatmaps, and by CMX to calculate location coordinates.
When positioning an AP on a map in Prime Infrastructure, one setting can be changed and pushed to the WLC’s configuration for that AP: the
antenna model selection. If you specify the antenna model from the AP’s positioning options (see Figure 6-5), Prime Infrastructure will
automatically push the antenna to gain configuration to the WLC. This particular behavior is present with what we will refer to as the “old”
generation of maps under Maps > Wireless Maps > Site Maps (Deprecated), and you can see a quick example of it in Figure 6-5.
335
||||||||||||||||||||
||||||||||||||||||||
336
Technet24
||||||||||||||||||||
||||||||||||||||||||
By default, Prime Infrastructure orients an AP with internal antennas with an azimuth of 90 degrees and an elevation of 0 degrees. This
corresponds to an AP mounted with the upper side of the Cisco logo pointing south (toward the lower part of the floor map) and the Cisco logo
facing down to the ground. It’s the typical installation of an AP on the ceiling, and Figure 6-8 shows an example of such an orientation in Prime
Infrastructure.
Figure 6-8 Antenna Orientation for a 3700 Series AP on the Ceiling with the Upper Side of the Cisco Logo Pointing South and Its
Ethernet Ports Facing South Too
The antenna orientation in the application shows the navigation maps/wireless maps/site maps. The orientation on the ceiling with the
upper side of the CISCO logo pointing south and its ethernet ports facing south. The antenna type is shown Internal-3700-5GHz;
337
||||||||||||||||||||
||||||||||||||||||||
Figure 6-9 Antenna Orientation for an AP on an East Wall with the Cisco Logo Facing West
The antenna orientation in the application shows the navigation maps/wireless maps/site maps. The orientation for an AP on an east wall
with the CISCO logo facing west. The antenna type is shown Internal-3700-5GHz; integrated 3700i Omni antenna with a dipole gain of
6 decibels relative to an isotropic radiator. The azimuth angle reads 180 degrees and elevation angle reads 90.
For external dipole omnidirectional antennas (AIR-ANT2524DB-R, AIR-ANT2524DG-R, and AIR-ANT2524DW-R), you should think of
the arrow as perpendicular to the longitudinal axis of the antenna and to either of its “flat” sides. By default, Prime Infrastructure orients
external dipole antennas with an azimuth of 90 degrees and an elevation of 0 degrees. This corresponds to the antenna’s tip pointing down
to the ground and either of its “flat” sides parallel to the X axis of the map. When using external antennas, the AP orientation does not
matter, because only the external antenna’s installation and orientation determines the coverage area.
As an example, a dipole antenna with an azimuth of 0 degrees and an elevation of 45 degrees corresponds to the “donut” shape coverage
area tilted down to the left, when looking at it from the south side of the map. You can see an example of this configuration in Figure 6-10.
338
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figure 6-10 Dipole Antenna Orientation with an Azimuth of 0 Degrees and an Elevation of 45 Degrees
The antenna type shown in the screenshot is "AIR-ANT2524DB-R-5GHz" and dual-band of frequency 2.4 to 5 GigaHertz, and
dipole of gain 4 dbi. A map shows the coverage area tilted down to the left facing from the south side.
Another example, as shown in Figure 6-11, could be a dipole antenna with an azimuth of 0 degrees and an elevation of −45 degrees, which
corresponds to the “donut” shape coverage area tilted down to the right when looking at it from the south side of the map.
Figure 6-11 Dipole Antenna Orientation with an Azimuth of 0 Degrees and an Elevation of −45 Degrees
The antenna type shown in the screenshot is "AIR-ANT2524DB-R-5GHz" and dual-band of frequency 2.4 to 5 GigaHertz, and
dipole of gain 4 dbi. A map shows the coverage area tilted down to the right facing from the south side.
In the previous examples, to get an elevation of −45 or 45 degrees in the actual installation, you will have to turn the dipole in such a way
that the antenna’s bolt will allow you to tilt it. The arrow orientation does not change between one side and the other, because you are
dealing with an omnidirectional antenna.
External patch-like antennas (AIR-ANT2524V4C-R, AIR-ANT2566P4W-R, AIR-ANT2566D4M-R, and AIR-ANT2513P4M-N) have an
orientation arrow originating from the center of the antenna’s plate, perpendicular to the plate (pointing away). By default, Prime
339
||||||||||||||||||||
||||||||||||||||||||
Figure 6-12 Patch Antenna Orientation with an Azimuth of 90 Degrees and an Elevation of 0 Degrees
The vertically mounted antenna type shown in the screenshot is "AIR-ANT2566P4W-R-5GHz" and dual-band of frequency 2.4 to
5 GigaHertz, and dipole of gain 6 dbi. The plate of the antenna is facing south, and its cables are facing to the ground, and a map
beside shows the coverage area of the antenna.
Similarly, an AIR-ANT2566P4W-R with an azimuth of 90 degrees and an elevation of −90 degrees, as in Figure 6-13, would be mounted
with its plate facing down to the ground and the cables’ side pointing north: the orientation arrow in such a case would point down to the
ground too. This would correspond to an antenna horizontally mounted, on the ceiling for example, with its cable connectors pointing north
on the map.
Figure 6-13 Patch Antenna Orientation with an Azimuth of 90 Degrees and an Elevation of −90 Degrees
The horizontally mounted antenna type shown in the screenshot is "AIR-ANT2566P4W-R-5GHz" and dual-band of frequency 2.4
to 5 GigaHertz, and dipole of gain 6 dbi. The plate of the antenna is facing to the ground, and its cables are facing to the north, and
340
Technet24
||||||||||||||||||||
||||||||||||||||||||
High Availability
For additional redundancy and availability, you can deploy Prime Infrastructure servers as HA pairs: the high availability model is always with
two servers, one active and one standby. The monitoring and synchronization services between primary and secondary servers are SSL based
and run on TCP ports 1522 (Oracle/JDBC database connections) and 8082 (health monitoring via HTTPS). The two servers need IP
reachability, of course, and if you choose to deploy them on the same VLAN, you have the option of configuring a Virtual IP for the HA pair.
This option usually has the advantage of letting you point your network devices to one single management IP for SNMP traps and syslog, for
example. Each Prime Infrastructure server will keep using its real management IP to source all other traffic to those network devices.
If you choose to deploy Prime Infrastructure servers on different subnets or not to configure a Virtual IP, you need to make sure that network
devices are sending SNMP traps and syslog messages to the IPs of both servers, not to lose data in case of failover.
You have the option of two failover modes, manual or automatic, both having their pros and cons. Manual failover, as the word says, does not
have the advantage of automatic recovery if the active server fails. However, this mode could also avoid “split brain” scenarios where each
server automatically promotes itself to active because of a network reachability failure. Manual mode also avoids the issue of continuous
failover because of potential network latency issues between both nodes.
The high availability configuration is relatively straightforward and can be followed through the official administrator’s guide:
https://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/infrastructure/3-
2/admin/guide/bk_CiscoPrimeInfastructure_3_2_AdminGuide/bk_CiscoPrimeInfastructure_3_2_AdminGuide_chapter_01010.html#con_1104574
On top of the official guide, as a quick review of the requirements to keep in mind when setting up high availability for Prime Infrastructure,
here are the main steps you should consider:
Plan the high availability deployment model by choosing between having a Virtual IP for your pair of Prime Infrastructure servers or
keeping your servers reachable on their respective IP addresses if they cannot be deployed on the same subnet.
Verify that both your primary and secondary servers will be installed with the very same software versions, patches, and packages.
After the primary server’s installation, while installing the secondary server, verify that you specify the option for this server to be used as a
secondary for HA, and note down the authentication key that you will be asked right after this step: you will be asked for this key on the
primary server when activating HA.
After installing the secondary server and updating it, if needed, to the same version/patch/device bundle as the primary, on the primary
itself, you can activate high availability through the HA Configuration tab under Administration > Settings > High Availability. You will
be asked for the secondary server’s information, such as FQDN/IP and authentication key, as well as for options such as the Virtual IP or
the failover mode (for example, manual versus automatic).
The high availability setup itself might take some minutes, after which you will be able to connect to your Prime Infrastructure pair either
through the Virtual IP, if you chose to enable such an option, or through the primary or secondary server’s IP, depending on which one is active
at a given time.
Monitoring Tools: Troubleshooting Clients and Working with Reports, Alarms and Events, and Notifications
Along with managing network devices and configurations, another main goal of Prime Infrastructure is to provide network administrators with
troubleshooting and reporting tools. Although CCIE-level experts will prefer debugs on the WLC or AP, in daily network operations having a
centralized tool with data from different sources could be an easier starting point to isolate issues.
Comparing troubleshooting methodologies is not the primary goal of this book, but as a general guideline, one of the fastest and easiest options
for looking up a client’s details (or any other device’s details) in Prime Infrastructure is through the contextual search field on the top right of
341
||||||||||||||||||||
||||||||||||||||||||
342
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
344
Technet24
||||||||||||||||||||
||||||||||||||||||||
Configuring Jobs
Prime Infrastructure keeps collecting information from the network and the resources it interacts with through automatic or manual tasks,
referred to as jobs. You can find the full list of available jobs under Administration > Dashboards > Job Dashboard. The main goal of such
jobs is to keep refreshing the status of the network devices, their services, configurations, and so on without the administrator’s manual
intervention. For this reason, the vast majority of these jobs are scheduled to run automatically.
As an example, under the System Jobs > Status group, you can find the Wireless Configuration Audit job for synchronizing Prime
Infrastructure with the latest configuration on the WLC itself. It is usually scheduled to run once a day every day, but you can edit the
frequency.
Although usually not needed because by default all necessary jobs run automatically, you may, for example, want to check a specific job’s
schedule and collection status in case you cannot see data or statistics being updated for certain devices or services.
Security Operations
Security operations for wireless in Prime Infrastructure include three main functions: configuration auditing, rogue access points monitoring, and
wireless intrusion prevention systems (wIPS). The latter is tightly related to the Mobility Services Engine, and we delve more into it in the next
sections of this chapter.
Through configuration auditing, Prime Infrastructure performs different checks against a predefined list of settings and assigns a so-called
Security Index to the wireless deployment. These predefined settings include options such as Telnet/SSH configuration, client exclusion
measures, Management Frame Protection (MFP) parameters for WLANs, and so on. You can access the Security Index under Dashboard >
Wireless > Security. Whenever you configure an option in a way that it is deemed as “optimal” (in terms of security best practice compliance),
Prime Infrastructure raises the overall Security Index score, where a score of 100 represents the maximum value. However, not reaching a
Security Index of 100 does not mean that your wireless network is not secure. You should consider such an index as a general indicator for all
the security-related elements that you could configure in all the WLCs managed by Prime Infrastructure. Some of these elements are well-
known best practices, such as making sure that the default SNMP communities are not enabled, but not reaching the maximum score does not
necessarily mean that your networks are unsecure or unprotected.
Note
The Security Index that is evaluated against the WLCs’ configurations is updated by Prime Infrastructure after each run of the Wireless
Configuration Audit job (mentioned in the previous section).
Under the same Security dashboard, you can see a preview of wIPS attacks and rogue access points detection. From here, by clicking the
different counters, you can directly access the specific alarms and events raised for those categories.
345
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Tracking and positioning systems have been around for decades now, but more recently the market started asking for additional accuracy and
real-time location to address new needs related to how networks could interact with end users through mobile devices and applications. Such
new needs might include visitors’ flows analytics, campaigns advertisements, wayfinding applications, and so on.
Although outdoor location technologies such as GPS could still be a good complement, indoor location can usually better be achieved through
radio standards such as Wi-Fi or even the more recent Bluetooth Low Energy (BLE). Throughout the next paragraphs we present some of the
most common indoor location techniques, while leaving some special notes for BLE at the end: even if not all these techniques are directly
included in the Wireless CCIE blueprint, you may still benefit from some additional details in your daily job as a wireless expert.
Indoor tracking technologies are often also referred to as Real-Time Location Systems (RTLS) and can adopt different approaches.
This is the most basic location technique, which consists in determining the closest antenna to which the client is associated or simply passing
by, by using the strongest Received Signal Strength Indicator (RSSI) value, as shown in Figure 6-19.
348
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Lateration is a technique that calculates distance from well-known reference points on a map (for example, access points) by using data based
on the RSSI or Time Difference of Arrival (TDOA).
To achieve some better degree of accuracy of coordinates on a map, location solutions rely on distances calculated from at least three reference
points, as shown in Figure 6-21, at whose intersection you find the position of a wireless client calculated with the highest probability of success.
Because of that requirement for at least three reference points, we often use the term trilateration.
350
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Radio frequency identification (RFID) tags are not exactly a technique to calculate location coordinates but rather an alternative to standard
wireless clients for assets tracking. In contrast to passive tags, which emit when stimulated by a dedicated tag reader, active RFID tags are
battery powered devices of relatively contained dimensions, which can be attached to objects or persons and which keep emitting frames at a
specific, regular frequency and optionally with additional information, such as battery level, temperature, emergency button push, and so on.
These tags act as kind of wireless clients, in the sense that they actively send frames that are captured by access points and used for trilateration
with Probe RSSI: for such a reason we specifically talk about 802.11 active RFID tags as the only type of RFID tags supported for location
services with both MSE and CMX. Some tags do send probe requests too, but the most common frame type for location with 802.11 active
RFID tags is a Layer 2 multicast frame identifying the tag and containing the aforementioned additional options.
Assets tracking with RFID tags requires you to attach specific devices on objects or persons and configure them. Nevertheless, because of the
additional configuration and control you can apply to those tags, such a solution answers the need for actively tracking with a guaranteed
frequency and other services. By having more control on the wireless devices’ behavior, you can influence how often they are tracked. The
following are some common options you can find among the most popular RFID tags’ solutions:
Choice of channels, where to send multicast frames, so as to reduce the list of radio frequencies in use as the same configured for access
points. RFID tags can also send the same frame on all channels of the list at each beaconing period, to make sure all nearby access points
hear it on their corresponding frequencies.
Possibility to send frames more frequently only when in motion, to have the best of both power saving and tracking frequency.
352
Technet24
||||||||||||||||||||
||||||||||||||||||||
Sometimes also referred to as Direction of Arrival (DoA), this technique calculates a client’s location by determining the angle of incidence with
which the client’s signal arrives at the receiving sensor. This does not necessarily imply that one single access point instead of three or four
would be enough to achieve the same location results as with Probe RSSI. The major benefit of AoA, if implemented on all the same access
points as if planning for Probe RSSI, would be to increase the location accuracy up to one to three meters for the 50% probability and up to
around five meters for the 90% probability. Hyperlocation is the Cisco trademark for angle of arrival, and (always at the time of this book’s
writing and for the CCIE exam blueprint) it is a solution based on 3600 or 3700 series access points, with the WSM module, plus an additional
circular antenna mounted around the access points, as shown in Figure 6-23.
||||||||||||||||||||
||||||||||||||||||||
All the aforementioned tracking techniques are based on a wireless infrastructure, where the access points, the wireless LAN controller, and the
location engine of CMX are collecting data, aggregating them, and calculating location coordinates. Clients are playing a more “passive” role,
while the infrastructure does all the math to calculate (X,Y) coordinates and potentially feed them to third-party applications via APIs. From
here, those applications can use (X,Y) coordinates for analytic purposes, or even to offer location services back to those same wireless clients,
for wayfinding solutions through mobile apps or websites, for example. A quick visual representation of such a workflow is displayed in Figure
6-24.
354
Technet24
||||||||||||||||||||
||||||||||||||||||||
The format is of data size from 0 to 31 bytes divided into the following fields: Prefix (9 Bytes): Identifies Type, Proximity UUID (16
Bytes): BLE Device Unique ID (Close Range Tag Isolation), Major (2 Bytes): Group, Minor (2 Bytes): Subgroup, and TX Power (2
Bytes): For Range Estimation. At the bottom shows five fields: Apple iBeacon, Museum Tag 0E5427, Museum, Gaudi Expo, and
negative 59 milliwatt Decibel.
Mobile devices with a dedicated application (integrating the SDK from the company having manufactured the BLE emitters, to correctly
interpret BLE announcements) capture those BLE messages and then usually relay their information upstream, to an application server or
similar having the necessary horsepower for additional calculations. The application server, based on the information from all the messages
captured by and received from the mobile device, can then implement algorithms to determine the mobile device’s location or to derive other
services. At the stage where the beacons’ information arrived from the client to the application server, we are in a similar situation as with CMX
and wireless location, where the (X,Y) coordinate can be calculated by the location server and reused for additional services too. The main
difference with respect to wireless location techniques is that the mobile device plays the role of collecting the information and then relaying it
to an application (or location) server upstream that takes advantage of those data. This kind of workflow is represented in Figure 6-26.
Figure 6-26 Client and Infrastructure Interactions for Bluetooth Low Energy (BLE) Location
The input from three transmitters named "UUID Acme, Major 10, Minor 1, Tx 1," "UUID Acme, Major 10, Minor 2, Tx 2," and "UUID
Acme, Major 10, Minor 3, Tx 3" are captured using a mobile device in turn it is connected to a "Third-Party Mobile App Server" to
calculate distance. This information is again forwarded to the mobile device through a cloud and a Wi-Fi module.
Technically, you could support location services purely through BLE beacons while providing basic data connectivity to mobile devices even
through 4G, for example, so not necessarily Wi-Fi. However, BLE emitters are usually powered by batteries, which you would need to change
every 3–5 years. By their nature of “beacons,” the vast majority of BLE emitters on the market, even if from the same vendor and part of the
same solution, do not synchronize among them and do not communicate with a centralized management system either: to configure them, you
usually need to use a dedicated management application running on a mobile device and to approach each emitter one by one. Despite the lower
cost of a BLE emitter compared to a wireless access point, all these additional requirements might cause the overall cost of the location solution
to rise higher with BLE than with Wi-Fi. As shown in Figure 6-27, one common approach is to mix Wi-Fi and BLE location: you could use the
WLAN infrastructure to locate clients with a higher error margin in those areas, where just a few meters of precision are enough for the end
customer’s needs; in other zones with less than one meter proximity needs, you could then deploy BLE to fine tune the accuracy. A typical
example of such a mix could be wayfinding services inside an office or reservation options when approaching or entering meeting rooms.
355
||||||||||||||||||||
||||||||||||||||||||
Management Access
When installing CMX, you need to configure at least two accounts: cmxadmin for command line and upgrade operations, and admin for
accessing the graphical user interface with full rights for any operation. You can create more accounts in the local database with differentiated
privileges for accessing the different GUI’s tabs, as shown in Figure 6-28. Under the menu MANAGE > Users you can add new users and
define whether they will have full read and write access to one or more tabs of the GUI, or just general read access. If you configure a user with
the Read Only role, that account cannot be assigned with any other role; otherwise, it would start having write privileges too.
Figure 6-28 Users and Roles Configuration for Management Access of CMX
356
Technet24
||||||||||||||||||||
||||||||||||||||||||
Network Services
CMX provides three main services, through which others could be derived too. The main and most deployed one is the location services that
have been inherited from the former MSE and Location Appliance solutions. By working with the calculated location data, CMX also provides
the analytics service for additional statistics. Connect and engage on the other side designates an additional set of options for guest portals.
Some configuration guides or release notes might also often refer to CMX services as Detect, Connect, and Engage. Detect designates the
presence and location tracking capabilities, Connect indicates the guest portal services, and Engage represents the API options to feed external
third-party solutions, such as mobile application servers to engage with end users. It should be clear that CMX does not support features to
“wake up” mobile applications or send SMS and interact with end users. CMX provides a database that other applications can take advantage of
via APIs, to then communicate with mobile devices and end users according to data retrieved through those APIs. APIs for location services in
particular also support the so-called northbound notifications: these are push messages, in either JSON or XML format, sent on-the-fly as soon
as the event for which they are configured is triggered.
Note
The full specifications on all the supported API calls are available through any CMX installation by browsing to https://CMX_IP/apidocs/ and
selecting the corresponding service (for example, Location, Analytics, Presence). To try out API calls directly from these CMX menus you will
need to enter a username and password with the right API access privileges.
Different services in CMX 10.3 consume different levels of licenses. Location and Connect services, with all the corresponding APIs, consume
a Base license for every access point, from where clients are located or authenticated through guest portals. The Analytics service and its APIs
require an Advanced license per access point contributing to location calculations, whose data is then used for the analytics reports.
Location
We described different location techniques throughout the previous paragraphs: their level of accuracy will determine the precision of
coordinates calculated by CMX. One major distinction you may need to make about location is the difference between presence (that is, cell of
origin) and all other techniques.
Presence supports statistics based on whether a client’s MAC address is seen or not, with which RSSI, for how long, how often, and so on.
During the initial installation, CMX asks you to choose between a Location and a Presence mode. As also shown in Figure 6-29, the CMX
Presence installation primarily gives access to one main tab called PRESENCE ANALYTICS, which displays three types of statistics: counters
for the number of visitors, passerby and connected users, their dwell times, and their distribution with respect to repeated visits. A single access
point registered to a WLC (in the Mobility Express model too) is technically enough for presence to work; because there is no notion of placing
clients on a map, Prime Infrastructure is not part of this workflow. Controllers in CMX Presence can be added through the SYSTEM tab by
clicking the Settings button and by specifying the controller’s SNMP credentials.
357
||||||||||||||||||||
||||||||||||||||||||
Figure 6-29 Example of the PRESENCE ANALYTICS Tab in the CMX Presence Installation
The window displays the widgets such as total visitors, average dwell time, peak hour, conversion time, and top device maker. The
"Insights" option at the bottom shows the detailed Weekly and Monthly insights.
Presence supports grouping access points into sites: this is a local option on CMX itself that does not affect potential AP Groups or FlexConnect
Groups already configured on the WLC, if any.
You can think of graphs and numbers reported by CMX Presence as trends of how crowded a specific site could get: they do not expose
information on specific MAC addresses and cannot be used as precise counters for visitors, for example, because there is not necessarily a one-
to-one mapping in real life between a wireless device and a person. If needed, through APIs you can still access raw data of MAC addresses
from active clients, for example.
As for a typical CMX Location installation, CMX Presence also supports the same CONNECT & ENGAGE services (more on this later).
The CMX Location installation type is the one you need to be most familiar with for the Wireless CCIE exam and probably the one end
customers will need to deploy more often. This installation mode provides access to a dedicated tab for DETECT & LOCATE, where wireless
clients can be displayed on maps, as well as to an ANALYTICS tab displaying statistics derived from location coordinates.
For location services to work, you must import maps in CMX. These maps come directly from Prime Infrastructure, and correct AP placements
and orientations become fundamental for location accuracy. For importing maps to CMX you have several options:
Through the CMX graphical interface, under the SYSTEM tab, click the Settings button and browsing to Controllers and Maps Setup >
Import. From here you can specify credentials for CMX to connect to Prime Infrastructure directly and pull all the maps and WLC
coordinates.
This option will import all maps and all controllers from Prime Infrastructure to CMX. Although you can still delete unneeded plans and
WLCs afterward, you may probably want to import only specific ones.
Prime Infrastructure 3.2 supports an option to push maps to CMX after having added CMX itself to Prime Infrastructure. You can find this
under Services > Mobility Services > Connected Mobile Experiences by selecting an already added CMX server from the list and
clicking Import Map to CMX. This method allows selecting specific maps only.
The third option, which is also the one preferred by the authors of this book, is to manually export maps from Prime Infrastructure in a
.tar.gz compressed file and then import that very same file in CMX.
You can export maps from Prime Infrastructure under Maps > Wireless Maps > Site Maps (New!) by clicking Export > Map Archive on
the top-right option of the page. From the right side panel you can select the exact floors you would like to export, and then click Generate
Map Archive to download the needed file, as shown in Figure 6-30.
358
Technet24
||||||||||||||||||||
||||||||||||||||||||
Back in CMX, you can import the map file under the SYSTEM tab by clicking the Settings button and browsing to Controllers and Maps
Setup > Advanced: here you’ll find an option to import maps through the file generated from Prime Infrastructure.
Although it could take a few more seconds than the other two options, adding controllers and maps in a manual fashion in CMX usually
allows a bit more visibility on exactly which maps to import and also allows some easier troubleshooting if something accidentally fails in
the process.
Under the same Advanced settings for importing the maps file in CMX, you can also find all the fields to point CMX to the controller(s). Along
with the manual maps import process, this should be the preferred approach to declare controllers too.
A WLC is added in CMX by specifying its SNMP credentials. These are needed for CMX to go and configure the WLC directly, with all the
required settings for the Self-Signed Certificate (SSC) key hash (more on this later in the NMSP section).
Note
When a controller is configured to send data to CMX, it does so for all its access points; however, this does not mean that CMX is consuming
licenses for all those access points. License consumption for location and other services is based on the access points on the maps, through
which CMX is supposed to track clients, interferers, and so on.
For example, if a WLC has 100 access points registered but CMX has a map with only 50 of those access points positioned, the CMX license
consumption will be of 50 access points, despite the fact that the WLC is sending data for all 100 access points. As of today there is no direct
option to select which access points contribute to location calculations and consume licenses: the main technique to filter out access points is to
import a map with just the wanted access points in it.
After configuring maps and controllers in CMX, you should start seeing clients, interferers (BLE emitters included), and RFID tags being
tracked. You can select exactly which categories among these three to track under the SYSTEM tab, by clicking the Settings button and the
Tracking option.
Under the same Settings menu, the Filtering options let you modify some general parameters to include or exclude specific data.
The Duty Cycle Cutoff specifies the duty cycle percentage, for which CMX should not track interferers: the default value of 0 means that CMX
will track all interferers.
The RSSI Cutoff for probing clients determines with which dBm value CMX starts discarding RSSI values if three or more values with a higher
RSSI are already available for location calculations. For example, if you configure the RSSI Cutoff at −85 dBm and CMX receives
measurements of −47 dBm, −68 dBm, and −93 dBm for the same client from three different access points, it still uses the one at −93 dBm. For
the same RSSI Cutoff configuration, if CMX receives measurements of −47 dBm, −68 dBm, −76 dBm, −89 dBm, and −93 dBm for the same
client, it discards those at −89 dBm and −93 dBm because it already has three usable ones above the configured cutoff limit of −85 dBm. Other
Filtering parameters are probably self-explanatory, but it is worth mentioning the option Enable Locally Administered MAC Filtering, which is
checked by default. Thanks to this setting, CMX discards all random and temporary MAC addresses self-assigned by some client vendors while
probing, using the specific bit set to identify them as locally administered, which we discussed in the previous section when describing Probe
RSSI and FastLocate tracking techniques.
Among other settings, you should probably be aware of options in the Location Setup menu. Although you should usually leave these configured
as is by default, it might help knowing some of their main behaviors and goals:
Enable OW (Outer Walls) Location is an ancient inheritance from the former MSE and Location Appliance solutions, which is not being
used by CMX anymore but was left there for some backward compatibility corner cases. Its purpose was to take into account walls with
attenuations higher than 13 dB, if configured on maps.
Location calculations do not take into account obstacles and their attenuations as configured through the map editor in Prime Infrastructure.
359
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Analytics
The CMX name and services originated from the acquisition of the ThinkSmart company taking advantage of location coordinates via APIs to
provide analytics statistics and reports, and today we could say that the Analytics features in CMX are the strongest legacy from that specific
acquisition. By working with raw (X,Y) coordinates and correlating them based on time, number, and frequency of visits, as well as other
criteria, CMX provides reports with widgets spanning from basic wireless client counters to more advanced path analysis. A report is technically
a page with widgets that you can choose from a list; you can create multiple reports with different widgets, or even with the same widgets but
different time ranges, for example. As anticipated in the previous section, zones can be used in reports and widgets to compare data between
different areas on floor plans: these could be simple visitor count distributions between areas or, for example, users’ paths analysis starting from
a specific zone and ending in different ones.
CMX supports the following widgets to include in an Analytics report, some of which are also shown in Figure 6-32:
Visitors provides you with device counters, which you can organize by time of the day, areas, or by displaying overall daily counters. For
this last type of statistics, a visit is defined as the appearance of a device in a single area and on a single day, from 00:00 to 23:59.
If you try to edit a Visitors widget through the icon on its top-right corner, you can display what is called a Summary view. On top of the
361
||||||||||||||||||||
||||||||||||||||||||
The window displays the widgets such as total visitors, total zone visits, and total visits in the body of the window under "Count"
with their corresponding information. Below which shows a line graph represents "Daily trend" for "Devices Count" and a bar graph
for "Devices Count by Floor." The left pane displays: Count, Path, and Dwell Time under the option "Reports."
You can find well-detailed explanations of all the Analytics parameters and their uses directly on your CMX by browsing to the following URL:
https://CMX_IP/docs/pdf/analytics-doc.pdf
The shortest period of time supported by reports from the main analytics dashboard is for the current day. However, you also have access to a
dedicated real-time report under the Realtime option of the same ANALYTICS tab, from where you have access to a Wi-Fi Adoption and a
Device Counts widget that are continuously updated.
Other features of the analytics engine include a Heatmap menu, which shows concentration of wireless clients on floors, either real-time or by
playing it back in history. Colors of a heatmap here are not directly related to specific counters but simply display higher or lower concentrations
of wireless devices.
Although all these analytics options are available with the CMX Location installation mode, you could still take advantage of them for presence
use cases too. For example, if you generate visitors’ counts or dwell times for entire buildings, you don’t necessarily need precise location
coordinates on floors for those statistics to still provide realistic trends. The first four widget types from the aforementioned list are probably
more intuitive to use for this kind of presence analytics, but you can use Correlation and Path too by configuring buildings or campuses as focus
areas, in which case accurate location again might not play a fundamental role.
362
Technet24
||||||||||||||||||||
||||||||||||||||||||
Guest portal options on CMX are not dependent on location or analytics services or vice versa, but they provide additional tools to connect end
users and potentially increase location accuracy if using more advanced techniques such as FastLocate or Hyperlocation. In your daily job as a
wireless expert you may be confronted with the decision of which guest solution to deploy between portals on the WLC, CMX Connect, and
Identity Services Engine (ISE). Although not strictly related to the Wireless CCIE exam, it might be useful to clarify the main advantages and
use cases for each of the three:
The WLC’s internal portal is usually ideal for so-called hotspot scenarios, meaning when visitors should need to validate an Acceptable Use
Policy (AUP), for example, by checking a box for terms and conditions on the landing portal to then get directly authorized on the guest
network.
CMX Connect is generally recommended for the very same hotspot use case as the previous solution. However, with respect to the WLC’s
internal portal, CMX offers much easier and more advanced customization features for portals, along with options for redirecting to
different pages based on the client’s location and for integrating with social networks.
ISE is probably the most complete solution, allowing support for the same hotspot needs as the other two, as well as other use cases, such as
sponsored portals (for example, where visitors are asked for credentials generated by a “sponsor”) or self-registration (for example, visitors
generating their own credentials from the guest portal).
Figure 6-33 shows a quick positioning of the three main Cisco guest solutions (WLC, CMX, and ISE).
363
||||||||||||||||||||
||||||||||||||||||||
With this option enabled, the WLC replies with an HTTP OK to devices’ requests for external URLs on apple.com, hence not triggering the
minibrowser automatic pop-up. For a better end user’s experience, you may want to leave such an option disabled by default.
Another default option we tend to recommend leaving disabled is the support for HTTPS redirection. With such a feature the WLC could
redirect end users even when the initially requested external website is via HTTPS. Because of the nature of SSL, it is not possible to avoid
a certificate warning (the HTTPS session is kind of “hijacked” by the WLC to achieve this), and activating such a function is not optimal for
the WLC’s performance either. As a further note, you should keep in mind that because the CMX URL for the guest portal services is in
HTTPS, end users will see a certificate acceptance warning, because by default the CMX’s certificate is a self-signed one. To upload a
certificate signed by an external authority, refer to the “Getting Started” chapter in the official “Cisco CMX Configuration Guide, Release
10.3 and Later”:
https://www.cisco.com/c/en/us/td/docs/wireless/mse/10-3/cmx_config/b_cg_cmx103/getting_started_with_cisco_cmx.html
Alternatively, you might also disable the SSL mode on CMX through the following command, to support redirection via HTTP (and modify
the WLC’s preauthentication ACL and redirect URL accordingly):
cmxctl node sslmode disable
3. The WLC redirects the end user to the CMX URL by postponing additional information regarding the client’s MAC, the AP’s MAC, the
SSID name, and so on. It also includes a “switch_url” variable containing an HTTPS pointer to the virtual interface of the WLC itself. This
is an instruction to tell CMX to redirect the client back to the virtual interface at the end of the process. The full redirection URL from the
WLC looks like the following:
https://<CMX_IP>/visitor/login?switch_url=https://<VIRTUAL_IF>/login.html&ap_mac=<AP_MAC>&client_mac=
<CLIENT_MAC>&wlan=<SSID_NAME>
4. The end user at this point lands on the CMX Connect guest portal and needs to complete some tasks. These could range from a basic
acceptance of terms and conditions, to an authentication through a code received by SMS, to a login through social networks, and so on.
After completing tasks on the portal, CMX redirects the user back to the WLC’s virtual interface to signal the WLC that the client should
be successfully authorized on the WLAN. The redirection URL from CMX is similar to the following:
364
Technet24
||||||||||||||||||||
||||||||||||||||||||
A figure depicts the concept of LWA with CMX Connect. A tablet device, an Access Point, a WLAN Controller, and an MSE 3365
with Cisco CMX are shown along with the communications happening around them. 1. Association between the tablet and the
AP/WLC. 2. Redirection from AP/WLC to the tablet device with "https://<SERVER_IP>/visitor/Iogin?
switch_url=https://<VIRTUAL_IF>/login.html&ap_mac=<AP _MAC>&client_mac=<CLIENT_MAC>&wlan=<SSID_NAME>"
3. The tablet passes through the AP/WLC to reach the Web Portal, Cisco Live. The screen of the web portal has three text fields
for entering Name, Company Name, and Country. 4. Tablet Submits data to the portal. 5. Portal redirects to the WLC's virtual IF
with "https://<VIRTUAL_IF>/login.html?buttonClicked=4&err_flag=0&redirect_url=http://www.cisco.com." Tablet connects to
the Virtual interface where the following are true: No RADIUS Authentication, No RADIUS Attributes, No Per-User Policy, and All
Guests Have the Same Policies.
When creating a new portal in CMX under CONNECT & ENGAGE > Library > Portals, you can choose between some templates already
proposing different connection techniques, or you can customize your own portal with your preferred elements and connection options. Among
the connection and authentication approaches, we can distinguish the following:
Acceptance of terms and conditions and then a Submit button. This is probably the easiest and most effective option, and it should also be
the preferred one to deploy CMX Connect.
Registration form, whose fields (for example, Name, Email, Country) can be flagged as mandatory. This option adds some statistical
365
||||||||||||||||||||
||||||||||||||||||||
A figure portrays establishing a connection to Facebook WiFi through CMX Connect. A tablet device, a AP/WLC, a CMX, and the
Facebook WiFi are shown as icons and the communication between these network components is as follows. 1. Association
between the tablet and AP/WLC. 2. AP/WLC redirects the client to CMX. 3. The client device connects to CMX and the CMX
redirects the client to Facebook. 4. The client device tries to connect to Facebook. The Facebook WiFi screen has an option to
Checkin for free internet. After a successful attempt, the WiFi portal redirects the client to CMX with token XYZ. 5. The client
requests the CMX with the token XYZ. The CMX checks with Facebook for authenticating the token and receives a confirmation
from Facebook. 6. The CMX redirects the client to virtual interface. The client's HTTPS connection request is established.
Even if outside the scope of the Wireless CCIE exam, it is worth mentioning that the CMX Cloud supports two additional options for
authenticating guest users: vouchers and email delivery. Vouchers are codes that can be generated through the CMX interface and delivered
via email or printed directly. Similar to the SMS form, CMX Cloud also supports a field for end users to ask directly a voucher from the
guest portal, for it to be delivered via email.
While on the WLC you always configure the same local URL for redirecting to CMX, end users are actually presented (by CMX) with one
portal or another based on their location. Under CONNECT & ENGAGE > Connect Experiences you can assign portals to different locations,
at a campus, building, floor or even zone level.
One further option you should be aware of in CMX Connect is the support for Property Management System (PMS) solutions and policy plans.
Under certain assumptions, this could be the one exception to the previous statement in this section about the fact that with CMX Connect you
cannot implement per-user dynamic policies. PMS solutions are often used in hospitality environments, for example, to manage rooms and
services associated with their guests. CMX supports a connector to these external solutions allowing embedding PMS options in guest portals. It
also integrates so-called policy plans, which are rate limiting policies.
For policy plans to be supported, the configuration on the WLC should be slightly different than what we saw so far for web passthrough.
Instead of web passthrough, you should configure the Layer 2 security option for MAC Filtering and the Layer 3 security option for web policy
On MAC Filter Failure. Also, under the AAA Servers tab, you should point the WLAN to CMX as a RADIUS server. The behavior now is for
the WLC to attempt authenticating clients through their MAC addresses first, then to fall back to web authentication if that fails. When a
client’s MAC is authenticated against CMX during the initial connection, CMX is still not aware of that MAC address, so that authentication
fails and the WLC redirects the client to the guest portal on CMX. On the portal the client completes the needed actions, CMX redirects it to the
WLC’s virtual interface to be put into the RUN state. At this point the requirement would be for the client to manually reconnect, so that the
WLC can trigger a new MAC address authentication against CMX, which succeeds because CMX now already saw that MAC address. We
should clarify at this stage that a configuration step on CMX requires activating a FreeRadius server integrated into CMX itself, precisely to
authenticate MAC addresses. As a final result of the MAC address authentication, CMX acting as a RADIUS server passes back to the WLC the
366
Technet24
||||||||||||||||||||
||||||||||||||||||||
CleanAir
You can implement interferences detection and mitigation through the WLC and access points supporting the Cisco CleanAir technology. MSE
and CMX add on top location tracking, statistics, and history reports for such interferences. The location technique is based on trilateration for
interferers’ signal strength, similar to Probe RSSI in terms of accuracy levels. We mentioned both MSE and CMX because at the moment of this
book’s writing there still are some functional differences in interferences tracking between MSE 8.0 and CMX 10:
Both MSE and CMX support locating interferers on maps, and both solutions report (X,Y) coordinates to Prime Infrastructure for
interferences and zones of impact to be displayed on maps.
With MSE 8.0 you can integrate interferers information in Prime Infrastructure for client reports and troubleshooting, as well as for
CleanAir widgets under Dashboard > Wireless > CleanAir, for example. Figure 6-36 shows an example of these widgets with Air Quality
data already available without the need for MSE or CMX.
Figure 6-36 Example of CleanAir Widgets in Prime Infrastructure Without Any MSE or CMX
A screenshot shows the CleanAir Widget open in the Prime Infrastructure. Under Dashboard, Wireless is displayed in the window.
It has four tabs: Security, Mesh, CleanAir, and Contact Aware. The CleanAir tab is selected. The content area shows data related to
an 802.11b/g/n wireless connection. The start and end dates can be chosen from drop-down menus with the Zoom (time period) set
to 1 year. The result is in the form of a graph. At the bottom, another data related to an 802.11a/n wireless connection. On the right,
four more sections are listed and they are Worst 802.11a/n Interferers, Worst 802.11b/g/n Interferers, 802.11a/n Interferer Count,
and 802.11b/g/n Interferer Count.
With CMX 10.3 or earlier you cannot integrate interferers information in client reports and troubleshooting, and not in CleanAir widgets
either. However, you can still view CleanAir widgets in Prime Infrastructure for air quality statistics, because those data do not require MSE
or CMX to be displayed. It is not unlikely that future versions of Prime Infrastructure and CMX could support these types of information, as
with MSE 8.0 today.
Interferences detection plays an important role for BLE beacons location and management too. Although CMX has dedicated options and
menus to manage BLE emitters on maps, information on beacons are based on the whole CleanAir solution. Access points classify BLE beacons
as such, and pass data to the WLC always as part of “standard” CleanAir operations, which in turn push the information to CMX. It is CMX
that uses these specific data from CleanAir for dedicated features, separating BLE beacons from typical interferers.
367
||||||||||||||||||||
||||||||||||||||||||
Wireless Intrusion Prevention System (WIPS) generally refers to the set of features for detecting and, when possible, mitigating attacks on
wireless networks. The acronym is sometimes used to designate different solutions, depending on the available components. For the sake of
precision, we should first clarify the real terminology in Cisco Unified Wireless Networks:
Intrusion Detection System (IDS) represents the native set of options on a WLC, which allows detecting attacks based on a list of 17 pre-
canned signatures. Custom signatures are supported too, although they are very rarely implemented. On top of being already included in the
WLC’s features, the main advantage of IDS is that it enables an already good level of security by supporting detection for the most common
types of attacks. For these attacks you can configure SNMP traps on the WLC, as well as the corresponding alarms on Prime Infrastructure;
IDS does not support any prevention or mitigation feature.
It is important to keep in mind that the WLC alone supports some prevention and mitigation techniques using specific features, such as
Rogue AP containment (manual or autocontainment with rules) or Management Frame Protection (MFP), for example.
Adaptive WIPS (aWIPS) is the proper solution for advanced signatures and mitigation techniques, through the integration with MSE 8.0.
This is the solution that enables additional signatures detection and some prevention options, which we discuss in this section.
You may find some documentation still referring to IDS as WIPS, sometimes even including rogue access points detection under this acronym.
However, because only aWIPS supports some true prevention features, this is technically the solution we can also refer to as WIPS (or wIPS, in
some menus and guides).
MSE 8.0 is the software solution supporting aWIPS. When you integrate MSE in Prime Infrastructure for aWIPS and synchronize it with the
corresponding WLC, additional detection options are enabled on the access points, and the WLC will report such information to MSE for
further analysis and signature categorization. As a general approach, you could think of aWIPS as an even more advanced set of IDS signatures
and reporting tools. For some attacks, however, you can enable some containment techniques. You can enable WIPS signature detection on
access points through either of the following deployment options:
You can install access points in Monitor mode next to access points dedicated to serving clients, as shown in Figure 6-37. This is the oldest
and most effective technique, although it could be more expensive because of the higher number of access points to deploy. Its
effectiveness comes from the fact that a dedicated access point with both its radios monitoring the spectrum can scan both 2.4 GHz and 5
GHz frequency bands in parallel. An initial, general guideline is to plan for at least one access point in Monitor mode for every five access
points serving clients, but this may vary depending on other deployment requirements and physical structure of the environment. When
configuring the access point on the WLC, you need to set its AP Mode to Monitor and its AP Sub Mode to WIPS. Changing the AP Mode
to Monitor requires the access point to reboot, but changing the AP Sub Mode does not require any reboot.
Figure 6-37 WIPS Deployment Option with Data Serving and Monitor Mode APs
368
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figure 6-38 WIPS Deployment Option with 3600/3700 APs and the WSM Module
In the figure, the WiFi module with AP 3600/3700 with WSSI/WSM, configured for data, wIPS, and CleanAir is shown. The data is
on both standard bandwidths: 2.4 gigahertz and 5 gigahertz. The server is open for access through both 2.4 and 5 gigahertz. The
client accesses through either of the bandwidths.
To configure the WSM module for WIPS, you set the AP Sub Mode to WIPS while keeping the AP Mode set to local or FlexConnect mode,
for example, for client serving purposes.
The 2800 and 3800 series access points, apart from the standard 5 GHz radio, integrate a Flexible Radio Assignment (FRA) radio, which
could serve clients either on the 2.4 GHz (default behavior) or on the 5 GHz band. On top of that, the FRA radio also supports the same
monitoring capabilities as a WSM module for the 3600 and 3700 series access points. If you assign the monitor role to the FRA radio, as
shown in Figure 6-39, the standard 5 GHz radio can keep serving clients on that band and you can support the same WIPS options as with
the previous technique. When configuring the FRA radio for the monitor role on 2800/3800 access points, clients on the 2.4 GHz band will
not be supported anymore.
369
||||||||||||||||||||
||||||||||||||||||||
Figure 6-39 WIPS Deployment Option with 2800/3800 APs and the FRA Radio
In the figure, the WiFi module with AP 2800/3800, configured for data on 5 gigahertz, wIPS, and CleanAir on 2.4 and 5 gigahertz is
shown. The data is on both standard bandwidths: 2.4 gigahertz and 5 gigahertz. The server is open for access through both 2.4 and 5
gigahertz. The client accesses through either of the bandwidths. The server serves through 5 gigahertz. The bandwidths 2.5 and 5
gigahertz are open with channels from 1 to 161.
Even without WSM modules or access points supporting the FRA radio, one more option consists in keeping your access points configured
for serving clients (that is, in local or FlexConnect mode) and to set their AP Sub Mode to WIPS. As shown in Figure 6-40, this
configuration is called Enhanced Local Mode (ELM) and could be a good compromise for cost-sensitive deployments that still need some
WIPS capabilities. With this technique, the main purpose for the access points stays serving clients and, on a best-effort basis, it can go off-
channel to scan for attacks. Because of the best-effort nature of this option, ELM does not support the same full list of attacks as with the
previous techniques. The full lists of supported and unsupported attacks can be found in the official “Cisco Adaptive wIPS Deployment
Guide”:
https://www.cisco.com/c/en/us/td/docs/wireless/technology/wips/deployment/guide/WiPS_deployment_guide.html
Figure 6-40 WIPS Deployment Option with Enhanced Local Mode (ELM)
370
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figure 6-41 Interactions Between Prime Infrastructure, MSE, and the WLC for WIPS
In the figure, the Prime infrastructure is connected to two WLCs through SNMP (represented using dashed, double-headed arrows). It is
also connected to an MSE through SOAP/XML Over HTTP/HTTPS (solid, double-headed arrows). The MSE is connected to the two
WLCs, through NMSP Over SSL. Four Access Points are connected to the WLCs, two each, established through CAPWAP. Four
devices are connected wirelessly to the four access points, one each.
Apart from the MSE 8.0 installation itself, the entire configuration for MSE, WIPS profiles, and alarms is done through Prime Infrastructure. A
key concept to note is that aWIPS usually allows reporting, analyzing, and sometimes mitigating wireless attacks. It also supports location of
attackers on maps, although the accuracy depends on the deployment of access points with WIPS detection capabilities enabled. Location of
attackers is available if MSE 8.0 is configured for Context Aware Services (CAS) too, with the corresponding licenses.
For the purpose of the written Wireless CCIE exam, we will focus on the main theory behind deploying WIPS profiles and their options, leaving
all the details on the configuration steps to the official “Cisco Adaptive wIPS Deployment Guide”:
https://www.cisco.com/c/en/us/td/docs/wireless/technology/wips/deployment/guide/WiPS_deployment_guide.html
After you have installed MSE 8.0 and synchronized it with your WLC(s), a default WIPS profile is already applied to monitor attacks against
access points and SSIDs managed by your WLC(s). You can add new profiles, either by copying the default one and modifying it, for example,
or by starting from other available templates, which are predefined in Prime Infrastructure based on most common use cases (for example,
education, financial, retail). WIPS profiles in Prime Infrastructure are available under Services > Mobility Services > wIPS Profiles. After
having added a new profile, Prime Infrastructure asks you for an optional SSID Group to apply that profile to. If you don’t choose any SSID
Group, the WIPS profile by default monitors attacks launched against access points and WLANs in your infrastructure. From the SSID Group
List menu you can optionally specify whether attacks should be monitored against specific internal/external SSIDs, as shown in Figure 6-42.
371
||||||||||||||||||||
||||||||||||||||||||
372
Technet24
||||||||||||||||||||
||||||||||||||||||||
373
||||||||||||||||||||
||||||||||||||||||||
NMSP
Network Mobility Service Protocol (NMSP) is the Cisco proprietary protocol for all communications between the WLC and MSE or CMX. It is
TLS based on TCP port 16113 on the WLC, with CMX itself initiating the TLS tunnel, and requires a certificate’s hash validation between the
WLC and MSE/CMX. For such validation, when you point CMX to a WLC by specifying the controller’s SNMP credentials, CMX uses SNMP
to configure the WLC with the key hash from its own Self-Signed Certificate (SSC).
On the WLC you can see the key hash entry added by CMX under SECURITY > AAA > AP Policies > AP Authorization List, or through
the command show auth-list. An entry for CMX will show up with the value LBS-SSC-SHA256 (LBS, Location Based Services) under the
Certificate Type column. Usually you should not need to change this entry manually on the WLC, but if required you can find the key hash
value that CMX should have pushed to the WLC by directly typing the following command from the CMX’s CLI, through the cmxadmin
account: cmxctl config controllers show. The CMX’s certificate key hash used for the WLC is the one for SHA2 Key.
Another main requirement for NMSP to work is time synchronization between the WLC and CMX. The recommended best practice is to
configure NTP, for both the WLC and CMX toward the same NTP server (for Prime Infrastructure too). If NTP is not available, you should
configure the WLC’s clock to be the same or slightly ahead of the CMX’s one.
The easiest and quickest way to verify the NMSP connectivity between the WLC and CMX is through the commands show nmsp status on the
WLC and cmxctl config controllers show on CMX.
Note
Although not specifically part of the Wireless CCIE exam, you should be aware that the NMSP communication between the WLC and CMX
Cloud is based on HTTPS. This was introduced with AireOS 8.2, through a proxy HTTPS option and as a native HTTPS connection option on
the WLC as of AireOS 8.3.
Summary
As you may have noticed, as a CCIE Wireless candidate, you should be aware of the different roles played by MSE 8.0 and CMX 10, the
374
Technet24
||||||||||||||||||||
||||||||||||||||||||
375
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Let’s start with a quiz question: What is the second most configured feature in Cisco networking
devices? If you read the title of this chapter, then you probably guessed: QoS (the first one is
routing).
QoS is therefore a fundamental concept. However, to help you survive the complexities of the
CCIE lab exam, but also to help you face real deployment use cases, we need to dispel a few
legends. The first legend is that QoS is about lack of bandwidth and that adding bandwidth solves
the problem and removes the need for QoS. This is deeply untrue. QoS is about balance between
the incoming quantity of bits per second and the practical limitations of the link where these bits
must be sent.
Let’s look at a nonwireless example to help clarify this concept. Suppose that you need to send a
video flow over a 1 Gbps switch interface. The communicated bandwidth, 1 Gbps, is only an
approximation over time of the capacity of the link. One gigabit per second is the measure of the
transmission capability of the Ethernet port and its associated cable (over 1 second, this port can
transmit one billion bits). But behind the port resides a buffer (in fact probably more than one, each
buffer being allocated to a type of traffic), whose job is to store the incoming bits until they can be
sent on the line, and a scheduler, whose job is to send blocks of bits to the cable.
A high-end switch buffer can store 5.4 MB. If the switch port is built around the notion of four
queues, that’s 1.35 MB per queue. Now, your port can send 1 gigabit per second, which translates
to about 125 kilobytes per microseconds. If you map the buffer to the link speed, you see that the
buffer can store up to 10.8 ms of data before being filled up.
Suppose that your switch receives a flow of video packets, representing a modest 2 MB burst
intended to draw a full 32-color 1080p video frame. You can immediately see that, even if the port
is completely idle before the burst arrives from within the switch bus (let’s assume that the internal
377
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
QoS Design
Just as you do not start building a house without a blueprint, you also do not start configuring QoS
without a QoS blueprint. This blueprint lists the types of traffic that you expect in your network and
organizes these types into categories. As a Wireless CCIE, your job is not to build an enterprise
QoS blueprint. However, a basic understanding of what this blueprint covers will help you reconcile
the apparent inconsistencies between 802.11e QoS marking and DSCP/802.1p marking, and will
also show you why some vendors get it right and others do not.
The main concern behind this QoS blueprint, often called a QoS model, is about arbitration between
packets. Suppose you have two packets that get onto an interface (toward any type of medium).
Suppose that you have to decide which packet to send first (because your outgoing medium has a
slower data rate than wherever these two packets came from), or you have to decide to pick one to
send and drop the other (because your interface buffer cannot store the second packet, and because
the second packet will not be useful anymore if it is delayed, or for any other reason). If you have
built a QoS model, and if you know which packet belongs to which class in that model, you can
make a reasonable choice for each packet.
A very basic QoS model runs around four classes: real-time traffic (voice or real-time
conferencing), control traffic for these real-time flows (but this category also includes your network
control traffic, such as RIP updates), data, and everything else. Data is often called transactional
data, and it matches specific data traffic that you identified as business relevant and that you care
about, such as database traffic, email, FTP, backups, and the like. Everything else represents all
other traffic that may or may not be business relevant. If it is business relevant, it is not important
enough that it needed to be identified in the transactional data category.
380
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Although QoS design should be your first action, it implies a knowledge of QoS mechanisms and
categories. It is therefore useful to dwell on classification fundamentals, especially because Wi-Fi
has a heavy history in the classification field.
Classifying packets implies that you can identify the passing traffic. The highest classification level
resides at the application layer. Each application opens a certain number of sockets in the client
operating system to send traffic through the network. These sockets have different relative
importance for the performances of the application itself.
An example will help you grasp the principles. Take a voice application like Jabber. When the
application runs, your smartphone microphone records the room audio, including (hopefully) the
sound of your voice. Typically, such an application splits the audio into small chunks, for example,
of 20 milliseconds each.
Note
You will find that there can be a lot of complexity behind this process, and that the process
described here is not strictly valid for all applications. For example, some applications may slice
time in chunks of 20 ms but record only a 10-millisecond sample over that interval, and consider it
a good-enough representation of the overall 20 millisecond sound. Other applications will use 8 or
10 millisecond slices, for example.
Each 20-millisecond audio sample is converted into bits. The conversion process uses what is called
a codec (to “code” and “decode”). Each codec results in different quantities of bits for the same
audio sample. In general, codecs that generate more bits also render a sound with more nuances
than codecs with a smaller bit encoding. A well-known reference codec is G.711, which generates
about 160 bytes (1280 bits) of payload for each 20 ms sound sample. With 50 samples per second,
this codec consumes 64 kbps, to which you must add the overhead of all the headers (L2, L3, L4)
for the payload transmission. Other codecs, like PDC-EFR, consume only 8 kbps, at the price of a
less-nuanced representation of the captured audio. It is said to be more “compressed” than G.711.
Some codecs are also called elastic, in that they react to congestion by increasing the compression
temporarily. The art of compressing as much as possible, while still rendering a sound with a lot of
nuances, is a very active field of research, but you do not need to be a codec expert to pass the
CCIE Wireless exam.
As you use Jabber, the application opens a network socket to send the flow of audio to the network.
383
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Each packet can be marked with a label that identifies the type of traffic that it carries. Both Layer
3 headers (IPv4 and IPv6) and most media Layer 2 headers (including Ethernet and 802.11) allow
for such a label. However, Layer 2 headers get removed when a packet transits from one medium
to the other. This is true when a packet goes through a router. The router strips Layer 2 off, looks
up the destination IP address, finds the best interface to forward this packet, then builds the Layer
2 header that matches that next interface medium type before sending (serializing) the packet onto
the medium.
This Layer 2 removal also happens without a router. When your autonomous AP receives an
802.11 frame, it strips off the 802.11 header and replaces it with an 802.3 header before sending it
to the Ethernet interface. When the AP is managed by a controller, the AP encapsulates the entire
802.11 frame into CAPWAP and sends it to the WLC. The WLC looks at the interface where the
packet should be sent and then removes the 802.11 header to replace it (most likely) with an 802.3
header before sending it out.
In all cases, the original Layer 2 header is removed. For this reason, we say that the Layer 2 header
is only locally significant (it is valid only for the local medium, with its specific characteristics and
constraints). By contrast, the Layer 3 part of the packet is globally significant (it exists throughout
the entire packet journey). This is true for the entire header, but is also true for the QoS part of that
header. As a consequence, the QoS label positioned in the Layer 3 section of the packet expresses
385
||||||||||||||||||||
||||||||||||||||||||
386
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the figure, the location of the QoS field is presented. The parameters of the Layer 3
IPv4 is as follows: Version Length, ToS 1 Byte, Len, ID, Offset, TTL, Proto, FCS, IP-
SA, IP-DA, and Data. A zoomed-in view of the ToS 1 Byte is given as a set of 8
blocks, numbered 0 through 7, each representing one bit. The bits 0, 1, and 2 are
named the Precedence 3 Bits and the bits 3, 4, 5, 6, and 7 are named the Unused 5
Bits. Further, another set of 8 bits is given in a similar way, where the first 6 bits are
named the DSCP 6 bits and the last two bits are named the Unused for QoS 2 Bits.
Both DSCP and IP Precedence keep the rightmost bit at 0 (this bit is called MBZ, “must be zero”).
This means, among other things, that you should never find in a standard network an odd DSCP
value. All DSCP values are expected to be even numbers (again, unless the network is nonstandard
and the admin uses experimental QoS marking).
DSCP is more complex than IP Precedence because it further divides the 6 left bits into three
sections. As a CCIE Wireless, you do not need to be a QoS expert. In fact, you can probably
survive the exam with no clear knowledge of DSCP internals, but gaining some awareness will
undoubtedly help you design your networks’ QoS policies properly.
Within the DSCP 6-bit label, the three leftmost bits (the 3 MSBs) express the general importance of
the traffic, here again on scale from 000 to 111 (0 to 7 in decimal). “Importance” is a relative term.
In theory, you could decide that 101 would mean “super important,” while 110 would mean “don’t
care.” If you were to do so, you would be using experimental QoS. Experimental, because
translating this importance beyond your own network (into the WAN, for example) would become
pretty challenging, as any other network could mean anything they wanted with the same bits. To
simplify the label structure and help ensure end-to-end compatibility of packet markings between
networks, the IETF has worked on multiple RFCs that organize possible traffic types in various
categories, and other RFCs that suggest a standardized (that is, common for all) marking for these
387
||||||||||||||||||||
||||||||||||||||||||
388
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the figure, a block of 6 bits: 0 0 1 0 1 0, named AF11 equals DSCP 10 is given. A table
below with column headers Class and Value infer the following data. The column Value is
sub-divided into three more columns. Therefore, the data is as follows. Row 1 AF1, 001,
dp, 0; Row 2 AF2, 010, dp, 0; Row 3 AF3, 011, dp, 0; Row 4 AF4, 100, dp, 0; EF (46),
101, 11, 0; Row 5 CS3 (24), 011, 00, 0. The field dp from the first row is highlighted and
shown using a detailed-view. The detail is comprised as a table with three columns: Drop
Probability (dp), Value, and AF value. The table infers the following data. Row 1 Low, 01,
AF11; Row 2 Medium, 10, AF12; Row 3 High, 11, AF13.
The slight complexity of DSCP is that the class bits and the drop probability work in reverse logic.
The three leftmost bits represent the general traffic class, and the convention is that a higher
number means a traffic more sensitive to delay and loss (a traffic that you should delay, or drop
less, if possible). So you would delay or drop 010 before you delay or drop 100.
By contrast, the drop probability bits represent, within a class, which traffic should be dropped or
delayed first. This means that a drop probability of 11 is higher than a drop probability of 10, and
the traffic marked 11 will be dropped before the traffic marked 10.
Let’s take a few examples. Suppose that you have a packet marked 101 00 0. Class is 101, drop
probability is 00 (and MBZ is, of course, 0).
389
||||||||||||||||||||
||||||||||||||||||||
These DSCP numbers can be difficult to read and remember. Most of the time, the binary value is
converted to decimal. For example, 100 01 0 in binary is 34 in decimal. 34 is easier to remember,
but it does not show you the binary value that would help you check the class and drop probability
values.
The good news is that this general QoS architecture, called Diffserv (for Differentiated Services,
because different packets with different marking may receive different levels of service, from
“send first” to “delay or drop”), also includes a naming convention for the classes. This naming
convention is called the Per Hop Behavior (PHB). The convention works the following way:
When the general priority group (3 bits on the left) is set to 000, the group is called best-effort
service; no specific priority is marked.
When the general priority group contains values but the other bits (Drop Probability and MBZ)
are all set to 0, the QoS label is in fact contained in 3 bits. As such, it is equivalent to the IP
Precedence system mentioned earlier. It is also easily translated into other QoS systems
(802.11e or 802.1D) that use only 3 bits for QoS. That specific marking (only 3 bits of QoS) is
called a Class Selector (CS), because it represents the class itself, without any drop probability.
When the general priority group ranges from 001 to 100 (001, 010, 011, and 100) and contains
a drop probability value, the traffic is said to belong to the Assured Forwarding (AF) class.
Transmission will be assured, as long as there is a possibility to transmit.
When the general priority group is set to 101, traffic belongs to the Expedited Forwarding (EF)
class. This value is decimal 5, the same as the value used for voice with IP Precedence. In the
390
Technet24
||||||||||||||||||||
||||||||||||||||||||
When there is no drop probability, the class is called CS and a single number indicates the level. For
example, the PHB CS4 represents the DSCP value 100 00 0.
Figure 7-4 will help you visualize the different values. Notice that AF stops at AF4 (there is no
AF5, which would overlap with EF anyway, but there is also no AF6 or AF7). Beyond Voice, the
upper classes (CS6 and CS7) belong to a category that RFC 4594 (and others) call the Network
Control traffic. This is your EIGRP update or your CAPWAP control traffic. You are not expected
to have plenty of these, so a common class is enough. Also, you should never have to arbitrate
between packets in this class. In short, if you drop your CS6 traffic your network collapses, so you
391
||||||||||||||||||||
||||||||||||||||||||
In the table, the column headers are DSCP class, DSCP (bin), DSCP (hex), and DSCP
(dec). The table infers the following data. Row 1 reads none, 000000, 0x00, 0; Row 2 reads
cs1, 001000, 0x08, 8; Row 3 reads af11, 001010, 0x0A, 10; Row 4 reads af12, 001100,
0x0C, 12; Row 5 reads af13, 001110, 0x0E, 14; Row 6 reads af21, 010000, 0x10, 16; Row
7 reads af22, 010010, 0x12, 18; Row 8 reads af23, 010100, 0x14, 20; Row 9 reads cs3,
010110, 0x16, 22; Row 10 reads af31, 011000, 0x18, 24; Row 11 reads af32, 011010,
0x1A, 26; Row 12 reads af33, 011100, 0x1C, 28; Row 13 reads af41, 011110, 0x1E, 30;
392
Technet24
||||||||||||||||||||
||||||||||||||||||||
393
||||||||||||||||||||
||||||||||||||||||||
In the figure, the structured view of the traffic classes is given in the form of a table with
two columns. The classes are as follows. RFC 4594-Based Model DSCP; Network Control
(CS7); Internetwork Control CS6; Voice plus DSCP-Admit EF plus 44; Broadcast Video
CS5; Multimedia Conferencing AF4; Real-time Interactive CS4; Multimedia Streaming
AF3; Signaling CS3; Transactional Data AF2; OAM CS2; Bulk Data AF1; Scavenger CS1;
Best Effort DF.
394
Technet24
||||||||||||||||||||
||||||||||||||||||||
Notice that traffic higher in the list is not “more important.” It is usually more sensitive to delay and
loss (as you learned earlier). The reason why this is fundamental to the understanding of QoS is
“marking bargaining.” Throughout your QoS career, you will often encounter customers with
requirements like this:
Customer: I want to prioritize my business-relevant traffic. I use Spark audio.
You: I see with AVC that you also have Facetime audio traffic. We’ll remark this one as Best
Effort and will keep Spark audio as EF.
Customer: Wait, Facetime is not business relevant but it is still Voice, so it is delay sensitive.
You: Yes, but if we mark Facetime EF, it will compete with your business-relevant Spark audio
traffic.
Customer: Okay, but can’t you give it something higher than BE that shows that we care for our
employees’ personal calls, even if they are not business relevant? Something, like, say 38 or 42?
You: Dear customer, you have absolutely no understanding of QoS.
Your answer to the customer is very reasonable (at least technically). Each class will correspond to
specific configuration on switches, routers (and you will see soon, WLCs and APs). Facetime is
either in the same bucket as Spark and should be treated the same way (making sure that 50
packets per seconds can be forwarded with low delay, and so on), or it is not business relevant and
is sent as best effort (which means “We’ll do our best to forward these packets as fast as we can,
unless something more important slows us down”). There is no QoS bargaining, for multiple
reasons. One of them is that you probably do not have a QoS configuration for DSCP 42, as your
customer suggests. Another reason is that if you create a configuration for DSCP 42, you will have
to borrow buffers and queues that are now used for something else, and your Facetime packets will
compete with other traffic (for example, with the CEO daily broadcast). If you mark Facetime
“something else,” like CS4 or CS5, it will again conflict with other traffic.
These are the reasons why Table 7-1 represents a series of classes, each of which will correspond to
a specific set of configured parameters to service that class to best match its requirements and
needs. It does not mean that voice is more important than broadcast video, for example. The table
just lists typical traffic types and a label that can be applied to each traffic type. In turn, this label
will be used on each internetworking device to recognize the associated traffic. With the knowledge
of what this traffic type needs, each networking device will forward the packets in conditions that
will provide the best possible service, taking into account the current conditions of the network
links.
This understanding is also important to realize that Scavenger (CS1) is not “higher” than Best Effort
(CS0, 000 00 0), even if it is listed above BE. In fact, all your configurations will purposely send
395
||||||||||||||||||||
||||||||||||||||||||
DSCP may sound a bit complicated, but it is very efficient. We covered the IPv4 case; now let’s
spend a few minutes on IPv6. The good news is that IPv6 QoS marking follows the logic and
mechanics of IPv4. The IPv6 header also has an 8-bit field called the Traffic Class field, where you
can mark QoS. Just like for IPv4 QoS, we ignore the rightmost 2 bits. They are also called Explicit
Congestion Notice bits and are used on some media to inform the other end about a congestion on
the line. Because we do not use them in Wi-Fi and because they do not express a QoS category, we
ignore them.
The other 6 bits are the same as in the IPv4 header, so you can put your DSCP value there. This
makes DSCP easy to use. The same value and categories are expressed in the IPv4 and the IPv6
header, as shown in Figure 7-6.
In the figure, the parts of the header are given as a stacked structure. From top to bottom,
the parameters are as follows. The first layer: version, traffic class, and flow label. The
second layer: payload length, next header, hop limit. The third layer is source address and
the fourth layer is the destination address.
IPv6 adds another section in the header called the Flow Label. This field is not present in IPv4. It is
useful for QoS in general because it allows the sender to put a label on a traffic flow. This helps
identify all packets in a given flow, and helps classification. With labels, your intermediate
networking device can check the label and identify the traffic without having to look at ports or run
a deep packet inspection. This is useful in general, but you will not be tested on IPv6 Flow Labels
on the CCIE Wireless exam.
396
Technet24
||||||||||||||||||||
||||||||||||||||||||
Remember that Layer 3 QoS marks the global QoS intent for your packet, the general category to
which this packet should belong. Your packet is then transported across different media. Each
medium has specific characteristics and constraints, and they cannot all categorize QoS families
over 6 bits. You saw that DSCP used 6 bits, which translated into (in theory) 64 possible categories.
In fact, a count from CS7 to CS0 shows that we are only using 21 values, not 64. However, the
DSCP scale is open to 64 possibilities, and your network can decide to implement some
experimental values if needed.
Many Layer 2 mediums do not have the possibility of expressing 64 levels of categorization
because of physical limitations. Switches, for example, build transmission buffers. You may
remember from the section “The Notion of Differentiated Treatment” that the general buffer is split
into subbuffers for each type of traffic category. If you had to build 64 subbuffers, each of them
would be too small to practically be useful or your general buffer would have to be enormous. In
both cases, prioritizing 64 categories over a single line does not make much processing sense when
you are expected to switch packets at line rate (1 Gbps or 10 Gbps). However, most switches can
use DSCP but they use an 8- or 12-queue model.
The Ethernet world was the first to implement a QoS labeling system. It was built around 3 bits (8
categories, with values ranging from 0 to 7). The initial IP Precedence system at the IP layer was
founded on the idea that there would be an equivalence between the Layer 2 and the Layer 3 QoS
categories. But as you know, DSCP expanded the model. Today, the Ethernet world is aware that
using L3 QoS is reasonable and that Layer 2 should translate the DSCP value, when needed, into
the (older) Ethernet 3-bit model. You will find many switches that understand the Ethernet 3-bit
QoS model but only use the DSCP value for their traffic classification and prioritization.
You are not taking a Routing and Switching CCIE, so you do not need to be an expert in Layer 2
QoS. However, 802.11 got its inspiration from 802.1 QoS, so it may be useful for you to see the
background picture.
That picture may be confusing for non-Switching people, because 802.1 QoS appeared historically
in several protocols, and you may have heard of 802.1p, 802.1D, and 802.1Q. In fact, it is just a
question of historic perspective. 802.1p is the name of an IEEE task group that designed QoS
marking at the MAC layer. Being an 802.1 branch, the target was primarily Ethernet. They worked
between 1995 and 1998. The result of their work was published in the 802.1D standard.
Note
In the 802.1 world, lower cases are task groups, like 802.1p, and capital letters are full standards,
like 802.1D. This is different from 802.11, where there is only one standard and the standard itself
has no added letter. Lower cases are amended to the standard (like 802.11ac), and capital letters
indicate deprecated amendments, usually politely named “recommended practices,” like 802.11F.
397
||||||||||||||||||||
||||||||||||||||||||
Caution
Table 7-2 is not what the original 802.1p-1998 or 802.1D said. We’ll come back to this point soon.
However, this is the current practice today, based on 802.1Q.
You see that there is a natural mapping from DSCP CS classes to these 8 values. CS7 and CS6 map
to CoS 7 and 6, respectively. Voice (EF) maps to CoS 5, Video (AF4 family) to CoS 4, the critical
Signaling (CS3) and Multimedia Streaming (AF3) map to CoS 3, all data (AF2 and CS2) maps to
CoS 2, BE is still 0, and Background (CS1) is CoS 1. You need to squeeze several classes into one,
and there are a few uncomfortable spots (like CS5), but overall, the DSCP to CoS mapping works.
It would be much more difficult to map the other way around, from CoS to DSCP, because you
would not be able to use the 21 values (not to mention 64); you would use only 8. This will come
back to us soon.
It is now time to look at 802.11 L2 QoS marking. It looks like we took the scenic route to get there,
but all you learned will help you make sense of what will look strange in the way 802.11 opposes
398
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the table, the column headers are User Priority (Binary), User Priority (Decimal),
802.1D Designation, Access Category, and Designation. For every two rows under the first
three columns, there is a single row under the last two columns. The data is as follows: Row
1 and Row 2 read: 111, 7, NC and 110, 6, VO, AC_VO Voice; Row 3 and Row 4 read:
101, 5, VI and 100, 4, CL AC_VI, Video; Row 5 and Row 6 read: 011, 3, EE, and 000, 0,
BE, AC_BE, Best Effort; Row 7 and Row 8 read: 010, 2, blank, and 001, 1, BK, AC_BK,
Background.
This table is an approximation of the table that appears as 20.i in 802.11e (and Table 10.1 in
802.11-2016). We added the binary value. A few elements are striking, in light of the previous
pages:
The labels are called priorities (User Priorities, UP). This is because there is not a lot of
buffering play available in a half-duplex medium. We will come back to this point very soon.
UPs are grouped two by two into access categories. Each access category has an intended
purpose (voice, and so on).
The values differ notably from the 802.1Q table. This is something a wireless expert must
understand.
Table 7-2 was 802.1Q. Table 7-3 is the original 802.1p table that was translated into 802.1D-2004:
Table 7-3 802.1p / 802.1D-2004 Classes
||||||||||||||||||||
||||||||||||||||||||
You can immediately see that there is a disconnect between 802.1p/802.1D and 802.1Q-2005.
Voice is 6 in 802.1p/802.1d-2004 but 5 in 802.1Q-2005. Similarly, Video gets 5 versus 4, not to
mention Excellent Effort downgraded from 4 to 3. At the same time, it looks like 802.11 is
following 802.1p/802.1D instead of following 802.1Q. What gives?
It all comes back to this notion of the QoS model. Back at the end of the 1990s, when the 802.1p
group was working, a standard model was around four queues, and a new trend was to add more
queues. The most urgent traffic was seen as Network Control, and the most urgent client data
traffic was seen as Voice. This is what gave birth to the 802.1p model.
When the 802.11e work started in 2000, it built on the work of a consortium, Wireless Multimedia
Extensions (WME), led by Microsoft, that was already trying to implement QoS markings among
Wi-Fi vendors. They (of course) followed the IEEE recommended values of the days (802.1p). The
802.11e draft was finished in 2003, and the 2003 to 2005 period was about finalizing details and
publishing the document.
In between, the IETF recognized that Network Control Traffic should be split into two categories:
level 6, which is the standard internetwork control traffic, and an additional category of even higher
level that should in fact be reserved for future use or for emergencies (label 7). In such a model,
Voice is not 6 anymore but 5, and Video moves from 5 to 4. This change was brought into the
inclusion of 802.1D into the revised 802.1Q-2005, but 802.11e was already finalized.
The result is a discrepancy between the standard 802.1Q marking for Voice and Video (5 and 4,
respectively), and the standard 802.11e marking for these same traffic types (6 and 5, respectively).
A common question you will face as an expert is: Why did 802.11 keep this old marking? Why did
they not update like 802.1Q did?
There are multiple answers to this question, but one key factor to keep in mind is that the 802.11e
marking is neither old, wrong, obsolete, nor anything along that line. Ethernet is a general medium
that can be found at the Access, Distribution, and Core layers. You expect any type of traffic on
such a medium, including routing updates. By contrast, Wi-Fi is commonly an access medium. You
do not expect EIGRP route updates to commonly fly between a wireless access point and a wireless
client (wireless backbones are different and are not access mediums). As such, there is no reason to
include an Internetwork Control category for 802.11 QoS. We already lose UP 7 if we keep it for
400
Technet24
||||||||||||||||||||
||||||||||||||||||||
In most scenarios, you should try to use DSCP to express your QoS intent (because DSCP is
independent from the local medium). However, there are cases where you need to work from UP
and decide the best DSCP, or when you need to decide which UP is best for a given DSCP value.
These requirements mean that you need to know what the recommended practices are for this
mapping. Fear not, there is a macro that we will examine in the “Configurations” section that will
help you configure the right numbers.
Downstream
Downstream traffic will come from the wire and will have a DSCP value. You need to decide
which UP to use. Table 7-4 shows the Cisco recommended mapping for a 12-class QoS model. You
will see each of 12 categories, their associated recommended DSCP marking (as per RFC 4594),
and the associated recommended UP marking. This mapping, shown in Figure 7-8, is not just
recommended by Cisco but is also an IETF standard (RFC 8325,
https://tools.ietf.org/html/rfc8325).
Table 7-4 UP to DSCP Recommended Mapping
||||||||||||||||||||
||||||||||||||||||||
In the figure, on the left, the layers of standard DSCP are given and on the right, the layers
of IEEE 802.11 Model are given. The 802.11 model has four layers comprised as follows,
from top to bottom: UP 7 and UP 6: Voice, Access, and Category; UP 5 and UP 6: Video,
Access, and Category; UP 3 and UP 0: Best Effort, Access, and Category; UP 2 and UP 1:
Background, Access, and Category. The mapping between the layers of these two models
is as follows. The last three layers of DSCP are mapped to UP 1, UP 2, and UP 0. The
fourth layer from the bottom of DSCP is also mapped to UP 0. Transactional Data is
mapped to UP 3. Signaling, Multimedia Streaming, and Multimedia Conferencing are
mapped to UP4. Real-time Interactive and Broadcast video are mapped to UP 5. Voice plus
DSCP-Admit is mapped to UP 6. Network Control and Internetwork Control point toward
UP 7, with a note that reads, Remark or Drop if not in use.
Notice that this model uses all UPs (except 7, still reserved “for future use”). This rich mapping
implies that some traffic, within the same access category (AC), will have different UPs. You will
see in the “Congestion Management” section that the access method (AIFSN, TXOP) is defined on
a per access category basis. This implies that both UPs in the same AC should have the same
priority level over the air. However, Cisco APs (and most professional devices) have an internal
buffering system that prioritizes higher UPs. In other words, although there is no difference
between UP 4 and UP 5 as far as serialization goes (the action of effectively sending the frame to
the air), the internal buffering mechanisms in Cisco APs will process the UP 5 frame in the buffer
402
Technet24
||||||||||||||||||||
||||||||||||||||||||
Upstream
Upstream traffic should come with DSCP marking (see the next section). In that case, you should
use DSCP and ignore UP. However, you may have networks and cases where UP is all you have to
work from, and you need to derive the DSCP value from the UP value. This is a very limiting case
because you have only 8 UP values to work from, and this does not fit a 12-class model. It also
makes it impossible to map to potentially 64 DSCP values. Even if you keep in mind that only 21
DSCP values are really used (counting all the AF, CS, and EF values in the DSCP table in the
previous pages), 8 UPs definitely is not enough. So you should avoid using UP to derive DSCP
whenever possible, but if you have to make this mapping, the recommended structure is shown in
Table 7-4.
Note that the mapping structure is very basic: For most UP values, simply map to the generic Class
Selector (CS). Then, map Video and Voice to their recommended DSCP value (AF41 and EF,
respectively).
Note
There is an important semantic exception to make for this table. You will see that UP 7 is
recommended to be mapped to CS 7. This is the mapping recommendation. This mapping
recommendation does not mean that you should have UP 7 or CS7 traffic in your network. It just
says that if you have UP 7 traffic in your network, the only logical DSCP value to which UP 7
could be mapped is CS 7.
However, you should not have any UP 7 (or DSCP CS 7) traffic in your network, first because
there is typically no network control traffic that would flow through your Wi-Fi access network
(unless your Wi-Fi link bridges to other networks, in which case it is not “access” anymore but has
become “infrastructure”), but also because CS7 is reserved for future use. So the actual
recommendation is to remap any incoming CS 7 traffic (or UP 7 traffic) to 0, because such marking
is not normal and would be the sign of something strange happening in your network (unless you
are consciously using this marking for some experimental purpose). You will see in the
“Configurations” section how this remarking is done.
Even if you have network control traffic flowing through your Wi-Fi network, the IETF
recommendation is in fact to use CS 6 and map it to UP 6. It will be in the same queue as your
voice traffic, which is not great. But UP 6 is better than UP 7 (which should stay reserved for future
use). The expectation is that you should not have a large volume of network control traffic anyway.
Therefore, positioning that traffic in the same queue as voice is acceptable because of the criticality
of such traffic and the expected low volume. If you have a large volume of network control traffic
over your Wi-Fi link, and you plan to also send real-time voice traffic on that link, you have a basic
403
||||||||||||||||||||
||||||||||||||||||||
Trust Boundary
At this point, you should understand that traffic can be identified (using various techniques,
including Deep Packet Inspection, or simple IP and port identification). After identification is
performed, you can apply a label to that traffic to express its category. This label can be applied at
Layer 2, at Layer 3, or both. Layer 3 expresses the general intent of the traffic, while Layer 2
expresses the local translation of that general intent. After a packet is labeled, you do not need to
perform classification again (you already know the traffic category)—that is, if you can trust that
label. This brings the notion of trust boundary. The trust boundary represents the point where you
start trusting the QoS label on a frame or packet. At that point, you examine each packet and
decide its classification and associated marking. Beyond that point, you know that packets have
been inspected and that their marking truly reflects their classification. Therefore, all you have to
do is act upon the packet QoS label (to prioritize, delay, or drop packets based on various
requirements examined in the next section).
But where should the trust boundary be located? Suppose that you receive a packet from a wireless
client and this packet is marked EF (DSCP 46). Should you automatically assume that this packet
carries voice traffic and should be prioritized accordingly, or should you examine the packet with
Deep Packet Inspection (DPI) and confirm what type of traffic is carried? You may then discover
that the packet is effectively voice, or that it is BitTorrent.
There is no right and wrong answer for this trust question, and Figure 7-9 illustrates the various
options. In a corporate environment, where you expect only corporate devices and corporate
activity, you may decide to fully trust your endpoints and clients. From an efficiency standpoint,
this scenario is optimal because you should classify and recognize traffic as close as possible to the
traffic source. If classification is done at the endpoint level, and all you have to do is act upon the
marking displayed in the endpoint packets, your network QoS tasks are all around prioritization and
congestion management. Classifying at the endpoint level removes the need for the network to
perform DPI. DPI is CPU-intensive, so there is a great advantage in trusting the client marking. In
that case, your trust boundary is right at the client level (points labeled 1 on the left).
404
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the figure, the following topology is portrayed and the devices are numbered 1 through 3
representing the markings. A modem, a router (numbered 2), two layer-three switches (first
one numbered 3), and a virtual router (numbered 1) are connected linearly. Similarly, a
switch (numbered 2), two layer-three switches (first one numbered 3), a virtual router
(numbered 1) are connected linearly just below the first linear topology. The router and the
switch numbered 2 are in the Access layer, the switches numbered 3 are in the Distribution
layer, the other set of switches are in the Core layer, and the virtual routers are in the
WAN aggregation layer. Both the virtual routers are connected to the internet. The router
in the access layer is connected to the switch of the bottom topology in the distribution
layer. Similarly, the switch in the access layer is connected to the switch in the top
topology in the distribution layer. Further, the switches in the distribution layer are cross-
connected to the switches in the Core layer. The switches in the core layer are cross-
connected to the virtual routers in the aggregation layer. A laptop, numbered 1, is
connected wirelessly while another laptop, also numbered 1, is wired to the switch in the
access layer.
However, in most networks, you cannot trust the client marking. This lack of trust in the client QoS
marking is not necessarily a lack of trust in the users (although this component is definitely present
in networks open to the general public) but is often a consequence of differences in QoS
implementations among platforms (in other words, your Windows clients will not mark a given
application the same way as your MacOS, iOS, or Android clients). Therefore, you either have to
document each operating system behavior for each application and create individual mappings and
trust rules accordingly, or run DPI at the access layer (on the access switch for wired clients and on
the AP or the WLC for wireless clients). In that case, your trust boundary moves from the client
location to the access layer. This location of the trust boundary is also acceptable. This is the reason
why you will see NBAR2/AVC be configured commonly on supporting access switches, and on
APs/WLCs. They are the access layer (labeled 2 in the illustration). On the other side of the
network, the first incoming router is the location where AVC rules will also be configured, because
the router is the incoming location for external traffic. (It is the point under your control that is
located as close as possible to the traffic source when traffic comes from the outside of your
network, and is therefore also labeled 1 in the illustration.)
405
||||||||||||||||||||
||||||||||||||||||||
Congestion Management
The trust boundary determines the location where you start trusting that the QoS label present on a
packet truly reflects the packet classification. Regardless of where the trust boundary lies, there will
be locations in the network (before or after the trust boundary) where you will have to act upon
packets to limit the effect of congestion. It is better if your trust boundary is before that congestion
location (otherwise you will act upon packets based on their QoS label without being sure that the
QoS label is really representing the packet class).
Multiple techniques are available to address existing or potential congestion. In QoS books, you will
see many sections on this topic because this is one of the main objectives of QoS. However, as a
wireless expert, you do not need deep insight into switching and routing techniques to address
observed or potential congestion. In the context of CCIE Wireless, this section is limited to the
techniques that are relevant to your field.
One key method to limit the effect of congestion is to avoid congestion in the first place. This
avoidance action is grouped under the general name of congestion avoidance.
In your CCNA studies, you heard about the 802.11 access method, Carrier Sense Multiple Access
with Collision Avoidance (CSMA/CA). This is one implementation of congestion avoidance, where
406
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the table, the column headers are EDCA/WMM AC, AIFS Number, CWmin, and
CWmax. The data inferred is as follows. Row 1 reads Legacy DCF, DIFS = 2, 15
superscript asterisk, 1023; Row 2 reads Voice, 2, 3, 7; Row 3 reads Video, 2, 7, 15; Row 4
reads Best Effort, 3, 15, 1023. Row 5 reads Background, 7, 15, 1023.
Also, it is the combined effect of the AIFS and the CW that provides a statistical differentiation for
each queue. As illustrated in Figure 7-11, you can see that voice has an obvious advantage over
best effort. Non-WMM traffic would have the same AIFS/DIFS as the voice queue, but the CW is
so much larger for best effort that voice gets access to the medium much more often than best
effort.
409
||||||||||||||||||||
||||||||||||||||||||
In the figure, the slots are in the order: Minimum Wait (AIFSN) and Random Backoff
Wait. They are as follows. Voice: SIFS, 2 slots, 0 to 3 slots; Video: SIFS, 2 slots, 0 to 7
slots; Best Effort: SIFS, 3 slots, 0 to 15 slots; Background: SIFS, 7 slots, 0 to 15 slots.
Note that if you capture traffic and look at the CW values, you may not see the right numbers. This
is because 802.11 defines them as exponents, as shown in Figure 7-12.
In the figure, a table denotes the slot calculation workaround. Above the table, a set of four
points conveys the AC Parameters. They are as follows. AC Parameters ACI 0 (Best
410
Technet24
||||||||||||||||||||
||||||||||||||||||||
A value of 3 (0011) would in fact mean (23 − 1), which is 7. This exponent view provides a
compact way to express numbers with the least number of consumed bits.
TXOP
Another technique to avoid congestion is to regulate the access to the medium. Wi-Fi is particular
in its medium access logic, where each packet requires an individual contention with its associated
random backoff timer. This logic is reasonably well adapted for data packets but can be detrimental
for real-time packets because the time counter does not get reset between packets. Let’s take a
worst-case scenario and suppose that your voice application samples audio every 10 milliseconds.
We saw before that the wireless card does not need 10 milliseconds to send 10 milliseconds worth
of audio, which translates to a few hundred bytes at most. However, keep in mind that each voice
packet carries a timestamp in its RTP header. Suppose that you have two audio frames in your
buffer. You send the first one, and at the end of the transmission the medium is still free. Yet, you
need to wait for a DIFS (or an AIFS), then count down from a random backoff number before
sending the next frame. Bad luck, the cell is congested, and other stations send before you get down
to 0. If you look back at Figure 7-10, you will see that voice and video have the same AIFS. You
will also see that voice can pick up to three slots for its backoff timer. By contrast, best effort AIFS
is 3 slots long, and the random backoff is picked in a contention window ranging from 0 to 15 slots.
This means that your voice packet may very well compete against a video or best effort packet, or
both, and lose both races (if these packets picked a low random backoff timer).
You may think that this is not a big issue because your countdown will resume (not restart), and
you will get to 0 eventually; you are right, at least on paper. One difficulty is that the original
802.11 said how long you should wait but did not say how long your transmission should be. 802.11
defined only a max MTU (an 802.11 frame is max 12,246 bits long, with the MAC and PHY
headers). If your competing stations sent that max MTU at 6 Mbps, the transmission time is about 2
milliseconds.
Note
411
||||||||||||||||||||
||||||||||||||||||||
In the table, the column headers are EDCA/WMM AC, TXOP (microseconds), and TXOP
(units). The data is as follows. Row 1 reads, Voice, 1504, 47; Row 2 reads Video, 3008, 94;
Row 3 reads Best Effort, 0, 0; Background, 0, 0.
Those values mean that, if you are transmitting traffic from the voice AC, after you gain access to
the medium with the AIFS/Random backoff mechanism, you can keep transmitting for up to 1504
microseconds. Because each voice packet is small, this maximizes your chances of emptying your
buffer. If you are transmitting a video flow, you can transmit even longer, up to 3 milliseconds. This
is because video packets are typically much larger than voice packets, so you will need more time
to empty your buffer. However, you should not use so much time that you would starve voice
412
Technet24
||||||||||||||||||||
||||||||||||||||||||
413
||||||||||||||||||||
||||||||||||||||||||
In the table, the column headers are AC, CWmin, CWmax, AIFSN, and TXOP Limit. The
TXOP Limit has four sub-columns: For PHYs Defined in Clause 15 and Clause 16, For
PHYs Defined in Clause 17, Clause 19, and Clause 21, For PHYs Defined in Clause 22,
and Other PHYs. The column For PHYs Defined in Clause 15 and Clause 16 is for
802.11/802.11b, the column For PHYs Defined in Clause 22 is for 802.11af (TV
Whitespace), and the column For PHYs Defined in Clause 17, Clause 19, and Clause 21 is
for 802.11g/a/n/ac. This column is highlighted. The data inferred is as follows. Row 1
reads, AC_BK, aCWmin, aCWmax, 7, 3.264 milliseconds, 2.528 milliseconds, 0, and 0.
Row 2 reads AC_BE, aCWmin, aCWmax, 3, 3.264 milliseconds, 2.528 milliseconds, 0, 0.
Row 3 reads AC_VI, (aCWmin plus 1) over 2 minus 1, aCWmin, 2, 6.016 milliseconds,
4.096 milliseconds, 22.56 milliseconds (BCU: 6 or 7 MHz), 16.92 milliseconds (BCU: 8
MHz), and 0. Row 4 reads, AC_VO, (aCWmin plus 1) over 4 minus 1, (aCWmin plus 1)
over 2 minus 1, 2, 3.264 milliseconds, 2.080 milliseconds, 11.28 milliseconds, (BCU: 6 or 7
MHz), 8.46 milliseconds (BCU: 8 MHz), 0.
From this table, you can see that two major changes were made:
Now each AC has its own TXOP. This allows the AP to provide limits to all queues, regardless
of whether a station is using blocks. BE and BK TXOPs values are close to those of voice,
because tests showed that this approximate equality was enough to provide a statistical
advantage to voice without starving the BE or BK queues. Video has a longer TXOP because it
414
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the table, the column headers are EDCA/WMM, AC TXOP (microseconds), and TXOP
(Units). The data is as follows. Row 1 reads Voice, 2080, 65. Row 2 reads Video, 4096,
128. Row 3 reads Best Effort, 2528, 79. Row 4 reads Background, 2528, 79.
CAC
TXOP is a way to provide more transmit opportunities to selected traffic categories, but also to
control and limit the amount of consecutive transmissions. 802.11e also implemented another
technique, directly derived from Unified Communications: Call Admission Control (CAC).
Caution
CAC is used in the Unified Communication (UC) world and the Wi-Fi world, but they are very
different features. UC CAC is typically implemented on a voice control server (like Cisco Unified
Communications Manager, CUCM) and tests end-to-end bandwidth and links performance. Based
on these measurements, the voice control server would allow or disallow specific calls. For
example, the server would block (busy tone) your call to number 1234 if it found that the end-to-
end link to the phone serving this number does not provide enough performances to allow a
415
||||||||||||||||||||
||||||||||||||||||||
416
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the screenshot, the WMM section of a beacon is displayed. Three access categories
based on Best Effort, Background, and Voice are shown. Under Access category - Voice,
three sub-sections are listed: ACI/AIFSN, ECW Min or Max, and TXOP Limit. In
ACI/AIFSN, two statements read ACM: Admission control not mandatory and AIFSN : 2.
In EXW Min or Max, two statements read, ECW Max: 3 (CW Max: 7) and ECW Min: 2
(CW Min: 3). TXOP Limit is 65. The mentioned data are highlighted and shown in the
screenshot.
802.11e states, and the WMM certification verifies, that a station should not send traffic in the
voice AC when ACM is enabled, without initially requesting service. This service request takes the
form of an Add Traffic Stream Request (ADDTS) sent by the client side. In this action frame, the
station describes the candidate’s traffic intended to be exchanged in the restricted AC. This
description is done in two fields: Traffic Specification (TSPEC), a mandatory field, and Traffic
Class (TCLAS), another, but optional, field.
Note
For this section, just like for the others, we only focus on 802.11e EDCA, the part of 802.11e that
describes distributed access function to the cell and that is implemented by vendors today. 802.11e
also describes a coordination function where the AP takes over the cell and distributes the right to
send (HCCA, Hybrid Coordinated Function Controlled Channel Access), but this mode is not
implemented widely (if at all), not implemented by Cisco, not tested by the Wi-Fi Alliance, and
therefore nonessential for your expertise in the real world and on the CCIE Wireless exam.
TSPEC describes what the intended traffic would look like and is the most important field for this
ADDTS exchange. You will find more details on this field in 802.11-2016 section 9.4.2.30. The key
elements of the TSPEC field are displayed in Figure 7-17.
417
||||||||||||||||||||
||||||||||||||||||||
In the figure, the field and the corresponding octets are as follows. Element ID 1, Length
(55) 1, TS Info 3, Nominal MSDU Size 2, Maximum MSDU Size 4, Minimum Service
Interval 4, Maximum Service Interval 4, Inactivity Internal 4, Suspension Interval 4,
Service Start Time 4, Minimum Data Rate 4, Mean Data Rate 4, Peak Data Rate 4, Burst
Size 4, Delay Bound 4, Minimum PHY Rate 4, Surplus Bandwidth Allowance 2, Medium
Time 2, DMG Attributes 0 or 2. The structure of the TS Info field is defined in the
following table. The bit start and end numbers, the element, and the number of bits are as
follows. B0, Traffic type, 1; B1 to B4, TSID, 4; B5 to B6, Direction, 2; B7 to B8, Access
Policy, 2; B9, Aggregation, 1; B10, APSD, 1; B11 to B13, User Priority, 3; B14 to B15, TS
Info Ack Policy, 2; B16, Schedule, 1; B17 to B23, Reserved, 7.
You do not need to know these fields by heart, but it is useful to understand them, to determine
why some stations support TSPEC whereas most others do not. TSPEC provides information about
the traffic, not only in terms of target UP but also in terms of minimum and maximum expected
frame sizes for this traffic, including possible bursts, possible silences between frames, the minimum
and maximum data rates needed to make the flow sustainable, and the airtime consumption for the
flow. Deep knowledge of both 802.11 and the traffic flow (codec) are needed to provide
information in the TSPEC field. This is the main reason why TSPEC support is common for hard
phones (for example, Cisco 8821 or 7926) but very uncommon for software applications on
smartphones. In this last case, app developers typically understand the software part (codec and so
on) but have no idea about Wi-Fi, and would have no clue on the max MSDU or the aggregation
support, because these parameters not only require Wi-Fi expertise (that they typically lack) but
also depend on the Wi-Fi driver characteristics. App developers have no information about the
possible platforms of Wi-Fi drivers. On their side, Wi-Fi driver developers have no information
418
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
BW Contracts
A last way to control congestion in Wi-Fi networks lies in bandwidth contracts. This is your
standard bandwidth limitation logic. In the wired world, you find two forms of this bandwidth
control, called policing and shaping, as shown in Figure 7-18.
A figure resembles a graph to capture the effect of traffic shaping. Two dashed, horizontal
lines are drawn at two different points of the vertical axis. The line at the top is Line Rate
and the line below it is Service Rate. Two curves represent Without Traffic Shaping and
With Traffic Shaping. The curve of Without traffic shaping peaks narrowly to reach the
line rate value, whenever there is an increase in traffic. The curve of with traffic shaping
smoothes down at the service rate level, evenly distributed instead of narrow peaks, in
places where the traffic is high.
Policing admits traffic up to a configured bandwidth and deletes the rest. In the figure, any traffic
above the service rate would be deleted. Shaping defines notions of buckets, where you can store
that excess traffic temporarily, then send it over time. In other words, shaping also limits the
bandwidth and delays the excess traffic to send it over a longer period of time. However, if the
temporary storage bucket gets full, the extra traffic will be deleted.
Wi-Fi also offers such options. You can control the bandwidth with a maximum traffic rate to
which you can also add a burst rate. This burst rate determines how much more than the target
bandwidth you will accept in your buffer. This additional traffic will be stored temporarily and sent
over time. However, even if the system displays values in kilobits per second, for example, you
420
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Configurations
The previous part provided the tools needed to understand and articulate the various QoS design
and strategies. This second part will guide you through the Cisco-specific configuration options.
Although this second part addresses content that you may face in the lab exam, we suggest you not
skip the first part of this chapter. Configuring without knowing why you click here and there is a
very deterministic way of falling into most of the traps in the lab exam!
AireOS
AireOS is the primary configuration interface that you will be expected to use in the exam. Make
sure you understand each configuration element, how it relates to the others, and what effect each
parameter will have on your critical traffic.
You have several tasks at hand to configure AireOS to support real-time applications. The first is to
decide on the QoS ceiling for your target WLANs (that is, the QoS profile). In most real-world
scenarios, the profile associated to a corporate SSID, where voice traffic is expected, should be
Platinum.
For guest WLANs, the QoS profile would typically be Best Effort or Bronze. Best Effort is
common, but Bronze is often recommended as best practice in networks where you want to ensure
that guest traffic will never compete with corporate traffic. If such a competition is not a concern,
then Best Effort is enough. When Bronze is chosen, all guest traffic gets marked down to AF11/UP
1. Therefore, no bandwidth contract is necessary in that case, because down-marking traffic is
424
Technet24
||||||||||||||||||||
||||||||||||||||||||
425
||||||||||||||||||||
||||||||||||||||||||
In the left side of the window, "Edit QoS profile, Edit QoS role data rates, and Edit
'ShowmeQoS" screens are displayed. The "Edit QoS profile" shows the sections "QoS
profile name, description, Per-User Bandwidth Contracts (Kbps) and Per-SSID Bandwidth
Contracts (Kbps)." In the second screenshot "Wireless" tab is selected that displays the
"Edit QoS role data rates" window with the sections "QoS role name and Per-User
bandwidth Contracts (Kbps)." In the "ShowmeQoS" window, "QoS" tab is selected. "Net
flow monitor and Fastlane" are set to "None and Enable" from spin boxes. In the "Override
Per-User Bandwidth contracts (Kbps) four fields are shown with Downstream and
Upstream values. "Override Per-SSID Bandwidth contracts (Kbps) four fields are shown
426
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
A cisco window is shown where "Wireless" tab is selected that displays a list in the
navigation pane. In the Content pane titled, "Edit QoS profile" the following sections are
shown. QoS profile name, description, Per-User bandwidth contracts, Per-SSID bandwidth
contracts, WLAN QoS parameters, and Wired QoS protocol. On the right, a table is shown
with the column headers reading "Profile name, Max downstream DSCP value, and
Maximum Upstream DSCP value."
The reason for not using bandwidth contract was explained in the previous section: as much as
possible, it is better to use QoS marking to create differentiated treatment for applications. Using
bandwidth contracts creates artificial static limits that do not take into account the traffic type, the
user location (close or far from the AP), and the general available airtime in the cell.
The maximum priority is the effective ceiling of the profile. You should remember that this ceiling
is expressed as an 802.11e AC (voice, video, best effort, and background). This means that the
maximum priority is intended for the wireless space, not the wired space (although it has an effect
on the wire, as we’ll see later). This ceiling means that no traffic will be marked higher than voice
downstream from the AP (for any SSID to which this QoS profile is associated).
428
Technet24
||||||||||||||||||||
||||||||||||||||||||
429
||||||||||||||||||||
||||||||||||||||||||
The devices laptop, mobile phone, and a tab are connected to an "Access point" through
the wireless connectivity in various orientations that is further connected to the "Layer 3
switch" labeled CAPWAP. To the right of the "Layer 3 switch," an "802.11Q trunk" is
shown with a "WLAN Controller" at the center and a "Stop" icon over it. At the top, a
leftward arrow is shown and at the bottom, a rightward arrow is shown. The devices and
the lines are connected by dotted lines. To the top of this, blocks are shown with the
CAPWAP packet numbers. The first block is divided into three "UP: 5, DSCP: 46, and
Payload." The second block is divided into two "DCSP: 34 and CAPWAP Encapsulated:
802.11, DCSP: 46, and Payload." The third block is divided into three "802.1p, DSCP,
CAPWAP Encapsulated: 802.11, DSCP: 46, and Payload." The fourth block is divided into
"802.1p, DSCP: 46, and Payload." The same set is shown at the bottom with the change in
the packet number of "UP" in the first block is labeled "6." At the top, the "DCSP: 34"
points to "UP: 5." The "DSCP: 46" points to the "CAPWAP Encapsulated DSCP: 46" and
"DSCP: 34." At the bottom, "UP: 6" points to "DSCP: 34" and the "CAPWAP
Encapsulated DSCP: 46" points to the DSCP: 46."
The WLC is going to convert the 802.3 header into an 802.11 header, then encapsulate the 802.11
frame into a CAPWAP header. The DSCP value, inside the encapsulated CAPWAP packet, is
unchanged (46); however, the Gold profile creates a QoS ceiling of AF 41 (DSCP 34). Therefore,
the WLC is going to cap the CAPWAP outer IP header to DSCP 34. In this example, because the
Wired QoS profile is set to none, the 802.1p (Layer 2 QoS over the Ethernet link) is ignored and
left at 0. Using DSCP is the recommended practice. Therefore, Wired QoS is expected to be left to
None.
Note
In older codes (before 7.x), the outer DSCP header would be left untouched (DSCP 46), and only
430
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
432
Technet24
||||||||||||||||||||
||||||||||||||||||||
Note
You will find online multiple documents that show you the QoS mapping for AireOS. Depending on
when this document was written, it can be pretty close to the current (on AireOS 8.3 and later)
mapping, or very far. Do not waste time trying to decide who is right and who is wrong. Most of the
time, the difference is when the document was written, not so much about whether the author knew
how to measure QoS.
Table 7-5 shows the current (AireOS 8.3 and later) default mapping:
Table 7-5 AireOS Default DSCP-UP Mapping
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
You see that a few values are highlighted, because the defaults do not match the best practices.
They are legacy recommendations. However, using defaults is also not the best practice, because
the defaults are based on the idea that you would use UP to DSCP mapping upstream, which you
should not do in most cases. So there is an expectation that you are going to override these defaults
anyway (even if you use UP upstream). Therefore, there is not a strong incentive to change the
AireOS code to hard code different default values (because you won’t use these defaults anyway,
whatever they are, because they assume “trust UP” to comply with backward compatibility rules).
Since AireOS 8.1MR1, you can create a custom DSCP to UP and UP to DSCP map. An optimized
version of this custom map can be created with a simple macro (Fastlane, examined later in this
section). However, you may want to understand the custom map command and structure, in case
you need to customize it by hand. The customization page is a global setting (applies to all SSIDs
and all bands) and is configured from Wireless > QOS > QoS map, as shown in Figure 7-22.
435
||||||||||||||||||||
||||||||||||||||||||
In the Cisco window, "Wireless" tab is selected that displays the Wireless list in the
navigation pane. The content pane titled "QoS Map Config" shows the "QoS map set to
enable (selected from a spin box)." A radio button "Trust: Trust DSCP Upstream" is
selected under "Up Stream" with Apply button. Downstream consists of the sections
"DSCP to UP map, Add DSCP exception, DSCP to UP map list, and DSCP Exception list."
DCSP TO UP map list shows a table with the headers Up, start DSCP, and End DSCP.
DSCP exception list shows a table with headers DSCP and UP.
From this page, you can set three configuration items:
Enable DSCP trust from the client
Configure a custom DSCP to UP map (called exceptions)
Configure a custom UP to DSCP map
436
Technet24
||||||||||||||||||||
||||||||||||||||||||
The recommended practice is to trust DSCP upstream. When this function is activated, the AP
looks at the DSCP field in the frames coming from wireless clients (instead of looking at the UP).
As detailed in the first part of this chapter, and shown in Figure 7-23, using DSCP instead of UP
allows for a richer translation of QoS intents between mediums.
The 802.11 frame consists of DSCP and UP, CAPWAP Packet consists of DSCP and
DSCP, and the IP Packet consists of DSCP. The DSCP and UP of the 802.11 frame points
to the two DSCP of the CAPWAP Packet. The first DSCP of the CAPWAP packet points
to the DSCP of the IP Packet. The Trust DSCP consists of two 6-Bit DSCP on both sides.
All the 6-Bits from the left DSCP are copied to the right DSCP. Trust UP is shown at the
top copies the first 3-Bits to the 6-Bit, where the last three bits are zeroed out. At the top,
an access point and a WLAN controller are shown that are connected by a cloud network.
Access point points between the 802.11 frames and CAPWAP packet and the WLAN
Controller points between the CAPWAP Packet and IP Packet. A laptop is connected to
the Access point through WI-Fi.
You can directly use the end-to-end intent for that packet, instead of using a 3-bit local L2 Wi-Fi
QoS intent to express intent across another medium (Ethernet) and possible routing hops, where
DSCP is more meaningful than Layer 2 values. Keep in mind that the action of the AP does not
change. Whether you trust DSCP or trust UP upstream, the AP still looks at the incoming value
437
||||||||||||||||||||
||||||||||||||||||||
The QoS configuration command reads (Cisco Controller) less than config qos qosmap up-
to-dscp-map 6 45 40 48. Text pointing the value 6 reads, This DSCP value range will
translate by default to this UP value (downstream) and this UP value will be default
CAPWAP outer header DSCP value (upstream)." "40 and 48" are encircled pointing to the
text "This DSCP value range will translate by default to this UP value (downstream)." "46"
points to a text reading "This UP value will be this default CAPWAP outer header DSCP
value (upstream)."
This complexity is reflected in the UI in AireOS 8.3 code as shown in Figure 7-22. In AireOS 8.4
and later, this direct translation of the CLI was replaced by an intent-oriented display, and DSCP to
UP was separated from UP to DSCP. The reason for the complexity comes from the fact that the
command is a direct translation from 802.11u. This amendment, published in 2011, contains
multiple provisions for HotSpot 2.0. In a context where Trusting UP was the norm (with all the
limitations expressed earlier that were well known to QoS experts working on 802.11u), 802.11u
allowed the AP to send to the client station an UP to DSCP map. This could be used by the station
to set the best UP for the upstream transmission, knowing the intended DSCP for a given traffic. In
other words, if you want to send a video packet, if you know that video receives AF 41 in your
438
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
EDCA Parameters
Another best practice set of parameters that you may want to change are the EDCA parameters, in
Wireless > 802.11a/n/ac (or 802.11b/g/n) > EDCA Parameters (CLI config advanced 802.11a /
802.11b edca-parameter). The default value is WMM, which matches the 802.11e standard
recommendations for EDCA. You may have some cases where the band is primarily designed for a
441
||||||||||||||||||||
||||||||||||||||||||
In the snapshot, "Wireless" tab is selected with "EDCA Profile" encircled under the
General section. A list for the "EDCA Profile" is displayed on the right reading "WMM,
Spectralink voice priority, Voice Optimized, and Voice and Video Optimized." WMM
points to a table with the column headers "AC, AIFSN, CWmin, CWmax, and TXOP" and
row headers "VO, VI, BE, and BK." Row 1 reads: 2, 2, 3, and 47. Row 2 reads: 2, 3, 4, and
94. Row 3 reads: Voice Optimized points to another table with the same headers. The
following values are changed in the following rows "AIFSN and VI: 5, AIFSN and BE: 5,
AIFSN and BK: 12, CWmin and BE: 5, CWmin and BK: 8, CWmax and VO: 4, CWmax
and VI: 5, TXOP and VO: 0, TXOP and VI: 0." The Voice and Video Optimized points
toward a table with the change of value in AIFSN and BE marked 12.
The blue color shows the changes from the standard WMM profile. Voice Optimized increases the
AIFSN for all queues except voice, and also increases some CWmin and CWmax values. Note that
Voice Optimized also sets the TXOP for voice and video to 0. This change fulfills two purposes:
As explained at the beginning of this chapter, a TXOP value offers transmit opportunities but
also limits the transmit duration. A value of 0 allows only one frame per service period but also
allows that frame to be the max duration allowed by the protocol. With 0, voice and video can
send large blocks, just like the other queues.
Some drivers (especially on hard phones) queue frames in a peculiar way. The software part of
the phone decides whether the packet needs to be sent to the queue, then subcontracts the
transmit part to the driver. The driver then looks at the TXOP and decides on the number of
frames that should be sent in the next service period. The frame burst is built, and the phone
442
Technet24
||||||||||||||||||||
||||||||||||||||||||
At this point, you have configured your QoS profiles, you likely have chosen to trust DSCP
upstream, and you have set your DSCP to UP and UP to DSCP maps. You have also chosen the
best EDCA parameter set. All this configuration relates to QoS, which means that your clients are
expected to have some support of QoS. In Wi-Fi terms, this means that they support WMM. If they
are 802.11n or 802.11ac compliant, they must support WMM, so it is likely that most of your
enterprise clients will be in this category.
Your next step is to go to the WLAN QoS tab and associate the right QoS profile: Platinum for an
enterprise hybrid BYOD WLAN, where voice is expected, as shown in Figure 7-26, and Best Effort
or Background for a guest WLAN.
443
||||||||||||||||||||
||||||||||||||||||||
In the Class window of the WLANs, QoS tab is selected that displays the fields where
Quality of Service (QoS) is set to platinum (voice) selected from a spin box and the
following fields are entered Application visibility, AVC profile, Flex AVC profile, NetFlow
monitor, and Fastlane. The bottom section Override Per-User Bandwidth Contracts (kbps)
shows four fields with downstream and upstream values. In the right screenshot, QoS tab is
selected in the class window. Under Override Per-SSID Bandwidth Contracts section, four
fields are shown with Downstream and Upstream values entered. In the WMM section,
WMM policy field shows a sublist where allowed is selected. Lync policy section shows
the fields audio, video, and application-sharing with Silver selected for all the fields from a
drop-down button.
Lower down the QoS tab, set WMM to Allowed or Required. If your stations support 802.11n or
802.11ac, they support WMM, and setting WMM to Required is the right choice. The Required
option was especially useful for smartphones. Many of them would prefer Best Effort and would
enable WMM only if the cell mandates it. In other words, set WMM to Allowed (allowing both
WMM and non-WMM devices and behavior), and these smartphones would not activate WMM.
Set WMM to Required, and these smartphones would activate WMM (because they have no
choice). Because WMM also activates QoS, WMM is much preferred over best effort. Using
WMM Required was a way to enforce this support.
However, using WMM Required means that non-WMM devices cannot join the WLAN (the
devices that do not support WMM, not the devices that would support it but are too lazy to activate
it by themselves). If you have such devices in your network, and you cannot upgrade them to
newer devices, you may have to set WMM to Allowed.
444
Technet24
||||||||||||||||||||
||||||||||||||||||||
The next parameter to consider is Call Admission Control. Recall that this is Wireless CAC, not
Unified Communications CAC. It is configured per band in Wireless > 802.11a/n/ac | 802.11b/g/n
> Media as shown in Figure 7-27 (CLI config 802.11b|802.11a cac).
In the Wireless window, the radio frequency 802.11a (5GHZ) is selected in the navigation
pane. In the content pane under media Video tab is selected that shows three sections Call
Admission Control (CAC), Per-Call SIP Bandwidth and Traffic Stream Metrics. The Call
Admission Control (CAC) section shows the fields where Admission control (ACM)
checkbox is selected. The sublist overlaps the checkbox where Load based is selected and
that points toward a text reading Use Load-based for TSPEC but static for SIP, Non -
WMM and another checkbox is selected for Expedited bandwidth. The reserved roaming
bandwidth (0 to 25) percent text box is marked 50, pointing to a text box reading up to 90
445
||||||||||||||||||||
||||||||||||||||||||
446
Technet24
||||||||||||||||||||
||||||||||||||||||||
The Non-Tspec clients like a laptop and a tab are connected to an "Access point" through
the wireless connectivity in various orientations that is further connected to the "Layer 3
switch" labeled "CAPWAP." To the right of the "Layer 3 switch," an "802.11Q trunk" is
shown with a "WLAN Controller" labeled "Platinum." At the top, a leftward arrow is
shown and at the bottom, a rightward arrow is shown. The devices and the lines are
connected by dotted lines. To the top of this, blocks are shown with the CAPWAP packet
numbers. The first block is divided into three "UP: 5, DSCP: 46, and Payload." The second
block is divided into two "DCSP: 34 and CAPWAP Encapsulated: 802.11, DCSP: 46, and
Payload." The third block is divided into three "802.1p, DSCP, CAPWAP Encapsulated:
802.11, DSCP: 46, and Payload." The fourth block is divided into "802.1p, DSCP: 46, and
Payload." The same set is shown at the bottom with the change in the packet number of
"UP" in the first block is labeled "6." At the top, the "UP: 5" points to "DSCP: 35." The
"CAPWAP Encapsulated DSCP: 46" points to "DSCP: 46." At the bottom, "DSCP: 46"
points to "UP: 0" of the first block labeled "Best Effort (BE)." The "DSCP" of the fourth
block points to "CAPWAP Encapsulated DSCP: 46" and DSCP: 46."
You should be aware that this feature works exactly as intended. Its purpose is to limit the voice
queue only to clients that are actually sending voice. They should describe their traffic first. The
exceptions are iOS and MacOS devices (see the “FastLane Configuration and Client Behavior”
section), because there is high certainty that traffic sent from these devices in UP 6 queue is indeed
going to be voice. The ACM feature limits the ability of, say, Linux BitTorrent users, from using the
highest priority queue for traffic that has nothing to do with voice. However, in a controlled
environment where you trust your client population and some devices may need access to this
queue without the possibility of TSPEC, this feature may be a limiting factor and should therefore
not be enabled.
Note
447
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
A good part of QoS configuration aims at providing efficient cell conditions for voice users. Part of
this effort resides in efficient cell design. RF design and site survey are out of scope of this section;
however, you should be aware that an assumption of cell design for real-time applications is that
the cell would be small (AP power similar to that of your clients, typically around 11 dBm to 14
dBm if your clients are smartphones). Additionally, low data rates would be disabled. In a typical
configuration, rates below 12 Mbps would be disabled, as shown in Figure 7-29. 12 Mbps would be
the first allowed rate, and set to Mandatory. The other higher rates would be set to Supported. 24
Mbps can also be set to Mandatory to allow for better multicast transmission. In higher density
cells, it is also common to set 24 Mbps as the first allowed (and Mandatory) rate, disabling any
lower rate. The choice depends on the cell density, and therefore the location. You should test
450
Technet24
||||||||||||||||||||
||||||||||||||||||||
The Wireless tab is selected in the Cisco window that displays a list of options in the
navigation pane. In the content pane the general and CCX Location Measurement sections
of 802.11b/g global parameters are shown. The General section shows the following fields
entered. 802.11b/g network status, 802.11g support short permeable, and DTPC Support
check boxes are selected for Enabled. Beacon Period (milliseconds), Fragmentation
threshold, Maximum allowed clients, and RSSI Threshold (negative 60 to negative 90dBm)
sections are labeled. Data rates are displayed on the right where, 11Mbps and 12Mbps are
set to Mandatory and Supported selected from a spin box and are encircled.
451
||||||||||||||||||||
||||||||||||||||||||
AVC Configuration
Another element of your QoS configuration includes Application Visibility and Control (AVC).
AVC performs deep packet inspection (DPI) to recognize close to 1,400 different applications,
including about 170 encrypted applications. AVC is therefore a central element of an end-to-end
QoS strategy. AVC can run on multiple platforms (WLCs, routers, and so on). However, there is a
CPU and memory load cost associated with application recognition. That cost may be negligible or
heavy, depending on the application mix transiting through your systems. In the real world, you
would carefully weigh that cost to decide the best locations to run DPI. You may decide to run
AVC on all routers, supporting switches, and on your WLC and APs, or just at selected locations.
Only testing could decide the impact of running AVC at a given device location. (None of this is a
consideration for the CCIE lab, where you can expect only a few clients.)
On FlexConnect APs running in local switching mode, AVC runs at the AP. In that case, AVC is a
subset of the full AVC. On local-mode APs and FlexConnect APs running in central switching
mode, AVC runs at the WLC. The location of the AVC task has practical consequences on QoS.
AVC allows you to rate-limit traffic, drop traffic, or change the QoS marking of target traffic. In
this last case, you should keep in mind that the AVC task runs inside the WLC and before the QoS
downstream profiling task, as illustrated in Figure 7-30.
452
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
In the Cisco window, "Wireless" tab is selected that displays a list in the navigation pane.
In the content pane "Enterprise mobility" of a rule in the AVC profile shows the fields
"application group, application name, action that is set to Mark (selected from a spin box)
and Dscp (O to 63) where "Platinum (Voice)" is selected. Another section is shown with
the fields "Application group, application group, and action" where "Action" is set to
"drop." Another box is shown at the bottom with the same fields where "Action" is set to
"Rate-Limit (selected from a drop-down button)."
Dropping is a simple action, taken at the WLC for both upstream and downstream mode and local
454
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the window, Wireless tab is selected. The left pane displays a list of the wireless
medium. AUTOQOS-AVC-PROFILE of the AVC profile displays a table in the content
pane with the column headers reading Application name, application group name, Action,
DSCP, Direction, and Rate Limit (average and burst rate) Kbps.
455
||||||||||||||||||||
||||||||||||||||||||
In the screenshot, the Cisco window is shown on the right side with the WLANs tab
selected. In the Content pane, Scan Defer Time (msecs) is set to 100. Under FlexConnect
section, Enabled checkbox is selected for FlexConnect local Switching. In the bottom
section, AVC Profiles is selected under Application Visibility And Control. The Edit
Mygroup, window under FlexConnect Groups is shown on the right. WLAN AVC Mapping
456
Technet24
||||||||||||||||||||
||||||||||||||||||||
457
||||||||||||||||||||
||||||||||||||||||||
458
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figure 7-34 Apple iOS and MacOS QoS Sockets and Mapping
The RFC 4594- Based model with DSCP are listed as follows. Network control: CS7,
Internetwork Control: CS7, Voice: EF, Broadcast Video: CS5, Multimedia
Conferencing: AF4, Real-time interactive: CS4, Multimedia Streaming: AF3, Signaling:
CS3, Low-Latency data: AF2, OAM: CS2, High throughput data: AF1, Scavenger:
CS1, and Best Effort: empty. The RFC shortcuts for the net service are
NET_SERVICE_TYPE_VO: Voice, NET_SERVICE_TYPE_VI: Multimedia
Conferencing, NET_SERVICE_TYPE_RV: Real-Time Interactive,
NET_SERVICE_TYPE_AV: Multimedia Streaming, NET_SERVICE_TYPE_SIG:
Signaling, NET_SERVICE_TYPE_RD: Low-Latency Data,
NET_SERVICE_TYPE_OAM: OAM, NET_SERVICE_TYPE_BK: High Throughput
Data, and NET_SERVICE_TYPE_BE: Best Effort. The IEEE 802.11 Model is shown
on the right. The DSCP points to the IEEE 802. Model. EF: UP6, Voice Access
Category (AC_VO); CS4 and CS3 points to UP5, Video Access Category (AC_VI);
CS2 and best effort: UP0, Best effort Access category (AC_BE) by solid lines. The
imaginary line connects the following, Multimedia conferencing and multimedia
streaming: UP5, Video Access category (AC_VI); AF2: UP0, Best effort Access
Category (AC_BE); and AF1: UP1, Background Access Category (AC_BK).
The operating system offers nine QoS classes available to app developers (as socket calls), and each
class receives a DSCP marking that follows IETF RFCs (e.g., RFC 4594). Each DSCP translates to
an UP marking that follows best practices, with a few minor exceptions. One exception worth
noting is that Apple chose to limit the current span of the mapping logic to four ACs, but only one
UP per AC, thus following the tradition of most other client and infrastructure vendors.
Cisco has worked extensively with Apple, also providing technical support to help app developers
understand the differences between the various classes and choose the best class for each of their
459
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
462
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the Edit Class window of the WLANs, QoS tab is selected that displays the fields
Quality of Service, Application visibility, AVC profile, flex VC profile, Netflow monitor,
and Fastlane. Fastlane is set to Enable (from a spin box). In the bottom section Override
Per-user Bandwidth Contracts (kbps) four fields Average data rate, burst data rate, average
real-time rate, and burst real-time rate with downstream and Upstream textboxes. "Clear"
button is displayed at the bottom. The steps involved are, 1: Configure Platinum Profile for
Voice -> UP6, Multicast and non-WMM Unicast -> BE; 2: Remove Bandwidth Limitation
for UDP on Platinum Profile; 3: Apply Platinum Profile to Your WLAN; 4: Apply EDCA
802.11revmc TXOP Values to Both Bands; 5: Enable Voice CAC, with 50 percent BW/
percent Roaming Limits; 6: Trust DSCP Upstream; 7: Create an Optimized UP-DSCP map,
Applied Downstream; 8: Create an Optimized AVC Profile for Well-known Applications
(AUTOQOS-AVC-PROFILE)."
Enabling this feature has two effects:
In the exchanges with Apple devices, a special handshake allows Apple devices to recognize
that Fastlane support is enabled on the SSID (the handshake format is proprietary).
Because enabling Fastlane indicates the will to support QoS, the Fastlane macro also configures
your WLC for best practices, as shown in Figure 7-36. In short, all the best practices described
in this chapter for QoS are configured. (The macro does not configure data rates, only QoS
features.)
After the iOS or Mac OS client device gets in range of a Cisco AP Meraki or AireOS 8.3 and later,
463
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Enhanced Roaming
Fastlane is often associated with another feature jointly supported by Apple and Cisco, this time
solely for iOS devices: enhanced roaming.
Enhanced roaming is only indirectly related to QoS and is about faster roaming. In this context, two
elements appear:
802.11k and 802.11v are enabled by default on any new WLAN. iOS devices support these
two protocols in the same way that Cisco implemented them. 802.11k provides a list of the
closest neighboring APs (up to 6) to the client joining the cell. This allows the client to have a
shortlist of channels to scan (up to 6, instead of more than 20) when later getting close to the
edge of the cell. 802.11v allows for a directed exchange when a client gets to the edge of the
cell and is in urgent need of a candidate channel and AP to roam to. The AP can provide such
next-best AP information based on the client location. Figure 7-37 contrasts 802.11k and
802.11v.
465
||||||||||||||||||||
||||||||||||||||||||
The "802.11k neighbor list" on the left shows a circle that displays the icons of an
Android mobile and an access point. Text near the android mobile reads, "What could
my next AP be?" and the text near the access point reads, "Here are the best 6 for
you." on the right, "802.11v solicited request" shows the same at the top and bottom
with text near the android mobile reading, "need to roam, what AP do you
recommend? and try this one" at the top and "Want to join your cell and Nah, load too
high, go there instead" at the bottom. The 802.11v Unsolicited request shows the
android in the outer circle and the access point reads "Your RSSI/rates are too low;
roam to there instead."
A new mode, Adaptive 802.11r, is created. iOS clients support 802.11r, an amendment
facilitating the fast exchange of WPA2 keying material during roaming events. However, many
networks do not implement 802.11r (even in combination with standard WPA2) because some
old clients, incompatible with 802.11r, may fail to associate if 802.11r is mentioned in the
WLAN parameters (even if, in hybrid mode, the client can use either 802.11r or regular
WPA2). As a consequence, a useful feature is widely underdeployed. Adaptive 11r leverages
the secret handshake that iOS and Cisco APs run, recognizing each other, to dynamically
enable 802.11r for individual iOS (iOS 10 and later) clients, while support for 802.11r is not
advertised in the cell.
Note
Adaptive 802.11r is the default security mechanism for new WLANs in AireOS 8.3 and later. It is
considered a best practice, unless you do not have any iOS clients in your network or unless you
enable 802.11r openly in the WLAN.
802.11k and 802.11v do not require specific configuration, because both are enabled by default in
the Advanced tab of the new WLANs you create in 8.3 and later, as shown in Figure 7-38.
466
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the edit class window, Advanced tab is selected. The Lync server under Lync is
disabled. The checkbox of neighbor list under 11k is selected. In the right side of the
window, the following sections are shown: Universal AP admin support, 11v BSS transition
support, tunneling, mDNS, TrustSec, and OpenDNS. Under 11v BSS transition support BSS
transition, BSS Max idle services, and directed multicast service checkboxes are selected
with Optimized roaming disassociation timer (0 to 40 TBTT) set to 40. Tunnel profile under
Tunneling is set to None. Open DNS mode and OpenDNS profile under OpenDNS are set
to Ignore and None (selected from a spin box).
However, you should be aware of the available options.
802.11k is enabled by checking the Neighbor List check box. This box should be checked by
default on new WLANs.
802.11k includes several modes. The mode activated by the Neighbor list option (and on iOS
devices) is the AP neighbor report. The client associates to the WLAN, and right after association
sends an Action frame of Category Radio Measurement, with a Neighbor Report Request. The AP
responds with another Action frame in the Radio Measurement family, which type is Neighbor
Report Response, as shown in Figure 7-39. 802.11k also allows the AP to ask the station for similar
reports, but that mode is not implemented in 8.3 or iOS. Also, the neighbor report could be asked at
any time, but iOS asks for the report only at association time. Other vendors also support 802.11k
and may make the request at other times (for example, some Intel enterprise chipsets make the
request when the AP RSSI falls below a target threshold). There is not really a mode that is better
than the other; the neighborhood is unlikely to dramatically change between the time the client
467
||||||||||||||||||||
||||||||||||||||||||
The 802.11k neighbor list is represented in a circle with an android mobile and a LAN. The
Android mobile represents What could my next AP be? pointing a code. The LAN
represents the Here are the best six for you that points toward another code.
By default, the Neighbor List includes neighboring APs and channel information only for the client
current band, which is best practice. You can check the Neighbor List Dual Band option to also
send information about neighbor information in the other band (for example, 2.4 GHz radios for a
client currently associated to a 5 GHz radio). Keep in mind that 5 GHz is usually considered better
than 2.4 GHz. In most cases, the cell coverage in 5 GHz should be sufficient to maintain the client
in that band across the entire floor, and iOS clients prefer the 5 GHz band anyway (this band is
scanned first, and preferred if at least one of the discovered APs signal in that band is above −65
dBm). Therefore, single-band (with the expectation of that band being 5 GHz) messaging is
preferred over dual-band messaging.
AireOS 8.3 also includes an Assisted Roaming Prediction Optimization option. This option is for
non-802.11k clients. Its logic is to construct the same neighbor list that 802.11k would build (best
neighboring APs) and force non-802.11k clients to prefer these neighbors. When the non-802.11k
client associates, a neighbor list is generated based on the client pre-association probes (which APs
heard the client best) and stored in the mobile station software data structure. Clients at different
locations have different lists because the client probes are seen with different RSSI values by
different neighbors. Because clients usually probe before any association or reassociation, this list is
constructed with the most updated probe data and predicts the next AP that the client is likely to
roam to. Then, when the client roams, association is denied to the APs not in that neighbor list. This
mode is a bit aggressive, because the client does not know the neighbor list. Therefore, it may have
undesirable side effects (such as the client temporarily dropping off Wi-Fi because the client is
468
Technet24
||||||||||||||||||||
||||||||||||||||||||
Prediction threshold: Minimum number of entries required in the prediction list for the
assisted roaming feature to be activated.
802.11v is activated by checking the BSS Transition option (should be enabled by default on new
WLANs).
In the 802.11v Solicited Request and 802.11v Unsolicited Optimized Roaming Request modes, the
AP suggests a better AP to an associated client. At that time, the AP can even be more directive,
and say “go to that AP, AND if you are not gone after delay X, I ‘may’ disconnect you”
(disassociation imminent bit). This bit is set if you check the Disassociation Imminent check box.
The delay is also advertised in the 802.11v message and configured in the Disassociation Timer
field. Note that the time unit is TBTT (Target Beacon Transmission Time), or beacon intervals.
The AP will not in fact disconnect the client unless you also configure Aggressive Load Balancing
(which needs to be enabled at the WLAN level in the Advanced tab, and can be edited in Wireless
> Advanced > RF Management > Load Balancing). Aggressive Load Balancing is not
recommended for networks with real-time applications. In these networks, you want to let your
client roam fast, even if the next AP is not the best, rather than be picky and force the client to
drop voice packets while you try to convince it to get to a better AP.
You can also disconnect the client after a number of TBTTs when also configuring Optimized
Roaming (in Wireless > Advanced > RF Management > Optimized Roaming). In that case, the
Optimized Roaming Disassociation Timer at the WLAN level will be used.
Note
Aggressive load balancing works based on the client probes, denying the client association requests
to APs that are not “the best” for that client.
Optimized roaming works based on signals, sending a deauthentication message to associated
clients when these clients’ signal fall below a configurable threshold. The expectation is that the
disconnected client will then try a better AP.
In the 802.11v section of the Advanced tab, you will see two items unrelated to roaming but related
to 802.11v. (802.11v is a 400-page long amendment, with multiple features around network
management to make the life of clients in the cell better.)
469
||||||||||||||||||||
||||||||||||||||||||
470
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the WLAN window, edit Mynet is selected. Security tab is selected within Layer 2
tab. The layer 2 security is set to none. Under Fast transition section, Over the DS
checkbox is selected that displays a list where adaptive is selected. In the right
window, the Security tab is selected. In the WPA+WPA2 parameters checkboxes are
selected for WPA2 policy and AES of WPA2 encryption. Under Authentication key
management, 'enable' checkbox is selected for PSK and FT 802.1X and FT PASK
checkbox are shown and highlighted.
Fast Transition Disable: 802.11r is disabled, not advertised, and not enabled, for any client.
Fast Transition Enable: FT is enabled and advertised in beacons and probe responses.
If you enable FT for your WLAN, you can choose a strict 802.11r key management mode, or a
hybrid mode:
If you set FT to Enable and choose key management to be either FT PSK or FT 802.1X, the
WLAN is strictly FT. Only 802.11r-compliant clients can associate to the cell.
If you set FT to Enable and choose key management to be a combination of FT and non-FT,
choosing either FT PSK and PSK, or FT 802.1X and 802.1X, the WLAN is hybrid. Both
802.11r and WPA2 are advertised in the beacons and probe responses. 802.11r clients are
expected to associate using 802.11r, whereas non-802.11r clients “should” associate using
standard WPA2.
If you set Fast Transition to Adaptive, your key management must be either 802.1X or PSK
(CCKM is a neutral option; you can enable it or not), as shown in Figure 7-40.
471
||||||||||||||||||||
||||||||||||||||||||
Video conferencing falls into the realm of real-time applications, and the recommendations in the
previous section apply. However, you may have other type of video traffic in the Multimedia
Streaming category (for example, your beloved CEO daily broadcast). In many networks, this one-
way flow is sent over multicast. Multicast is great for wired networks but has a major drawback for
Wi-Fi networks: it is sent per 802.11 requirements at one of the Basic (mandatory) rates. Only
legacy rates (802.11, 802.11b, 802.11g, or 802.11a) can be set to Basic. The result is that these
multicast flows will be sent at a suboptimal rate (instead of 802.11n or 802.11ac wherever
possible).
In most networks, you would set 12 Mbps and 24 Mbps as mandatory rates, and multicast flows
will be sent at the highest mandatory rate supported by all receiving stations. In an 802.11n or
802.11ac network, it is far more efficient to send 10 individual frames at 300 Mbps than a single
multicast frame at 24 Mbps (that all stations in the cell will receive, because the destination address
is multicast, even if they do not need it).
To work around this issue, you can configure media streams, also called VideoStreams. With media
streams, the WLC will keep track of wireless clients subscribing to targeted multicast flows using
IGMP membership reports. When such messages are transmitted by wireless clients, the WLC will
record the flow address that the client is subscribing to. Then, when such flows will be forwarded to
the client through the WLC, the WLC will unicast the flow to the client. This is the general
principle; the flow details are as follows:
Note
Please note that this section focuses on video flows, but media streams are in fact about multicast
streams, regardless of the payload they carry. You can configure media stream even if your
multicast flow carries something else than video, like multicast paging messages for voice badges
472
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
475
||||||||||||||||||||
||||||||||||||||||||
In the Cisco window, Controller tab is selected that displays a list in the navigation pane
where Multicast is selected. In the content pane, the fields of the multicast window are
displayed. The fields are as follows Enable global multitask mode, enable IGMP snooping,
enable MLD snooping checkboxes are selected, IGMP timeout (30 to 7200 seconds) and
MLD timeout (30 to 7200 seconds) is set to 20; IGMP query Interval (15 to 2400 seconds)
and MLD Query Interval (15 to 2400 seconds) are set to 20."
When Global Multicast Mode is disabled, incoming multicast traffic is not forwarded to clients and
is dropped at the WLC. Clients may try to subscribe to multicast flows by sending IGMP
membership reports, but the WLC will also drop these messages.
After Global Multicast Mode is enabled, multicast traffic can be forwarded to clients. The WLC
can then also forward the client’s membership reports to the wired infrastructure. Two modes are
possible:
Without IGMP (IPv4) or MLD (IPv6) snooping, the WLC forwards each membership report
message to the wired infrastructure. This mode is chatty. If 500 clients subscribe to the same
flow within a minute, the WLC will transparently relay each of these 500 messages upstream.
The upstream infrastructure directly sees the clients as the requesters (called the multicast
listeners).
With IGMP (IPv4) or MLD (IPv6) snooping, the WLC acts as a buffer. The WLC receives all
the membership reports from the wireless clients but only forwards upstream one membership
476
Technet24
||||||||||||||||||||
||||||||||||||||||||
477
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
479
||||||||||||||||||||
||||||||||||||||||||
Note
Be careful, this field represents the maximum bandwidth for media that is video traffic. Maximum
is 85%. However, the bandwidth allocated for all types of media traffic also cannot exceed 85%.
This total also includes the voice bandwidth. This has two consequences:
If you configure 50% bandwidth for Voice CAC and 65% for maximum media bandwidth, you
are telling the system that it should stop admitting TSPEC voice calls when voice calls
represent 50% of the bandwidth on the radio. But you are also saying that RRC should start
dropping (or sending as best effort) multicast flows representing more than 65% of the
bandwidth. The system will check each parameter individually. Because your total is more than
85% (it is actually more than 100%), you may face cases where media streams and voice suffer
from poor quality. As much as possible, make sure that Maximum Media Bandwidth and Voice
CAC Max RF Bandwidth (when configured) do not exceed 85%.
As you will see in the next section, you can also configure Video CAC. Voice CAC bandwidth
and Video CAC bandwidth together cannot exceed 85%. (The system throws an error if your
configuration exceeds this threshold.) You can consider the video admitted under Video CAC
as part of your multicast media flow, if that video is sent over multicast. In that case, it does not
make sense to have Video CAC different from Maximum Media Bandwidth. However, CAC
video can also be unicast. In this case, the numbers in Video CAC bandwidth and Maximum
Media Bandwidth are unrelated.
Sending unicast frames to an 802.11n/ac client is likely to be efficient. However, if the client is at
the cell edge at 6 Mbps, one multicast packet is likely better than many unicast slow packets.
Therefore, you can also configure the minimum PHY rate at which each multicast client should be
for the system to attempt unicast transmission instead of multicast (CLI config 802.11a cac media-
stream multicast-direct min-client-rate).
Efficiency (that is, speed of transmission) is one parameter. However, another advantage of unicast
frames is that they are acknowledged. This is a reason why you may want to keep the client PHY
480
Technet24
||||||||||||||||||||
||||||||||||||||||||
Bonjour/mDNS
If you use Apple iOS or macOS devices, you also have to manage another type of traffic, Bonjour.
In most cases, this traffic will not represent a large volume, but its structure has consequences on
your network efficiency.
Bonjour/mDNS Principles
Apple Bonjour is part of the larger multicast DNS (mDNS) family. Subscription and traffic for this
protocol are sent to the IPv4 address 224.0.0.251 and IPv6 address FF02::FB. These addresses are
part of the nonroutable family. They are well suited in a small home network where the Bonjour
traffic is expected to stay in the local subnet; however, this nonroutability is an issue for enterprise
networks. The WLC has multiple functions to help Bonjour traffic delivery, beyond simple
multicast forwarding. (Multicast forwarding may address the issue of letting clients receive Bonjour
traffic, but does not address the issue of Bonjour devices in different subnets needed to
communicate, and it is less efficient because it forwards all mDNS traffic without filtering for
specific services, or VLAN, or WLAN, or other options as you will see later.)
mDNS gateway: The WLC can act as a proxy to let mDNS wireless devices communicate with
481
||||||||||||||||||||
||||||||||||||||||||
Bonjour/mDNS Configuration
mDNS configuration may be challenging if you have a large number of devices, services, and
limited information about which device advertises (or needs) which type of service. It is common
for a single device (for example, Apple TV) to advertise multiple services, each with its own
associated code. Luckily, the CCIE exam is not about Apple services but about Wi-Fi
configurations. You should be able to select the services discovered automatically or the mDNS
browser to select the services you are asked to configure.
482
Technet24
||||||||||||||||||||
||||||||||||||||||||
To enable mDNS gateway and relay mDNS messages between subnets known by the WLC, check
the mDNS Global Snooping check box in the Controller > mDNS > general page (CLI config
mdns snooping), shown in Figure 7-43.
In the Cisco window, "Controller window" is selected that displays a list in the navigation
pane where mDNS is selected. In the content pane, "Global configuration" section shows
fields "mDNS global snooping checkbox is selected, mDNS policy, and Query Interval (10
to 120): 15 (mins)." The "Master service database" shows the fields: Select service, query
status, LSS status, and Origin." Below, a table is shown with the headers "Service name,
service string, query status, LSS status, and origin." Three Query status checkbox is
selected for the service name "HP_Photosmart_Printer_1, HP_Photosmart_Printer_2, and
HomeSharing. Origin shows spinboxes where ALL is selected.
483
||||||||||||||||||||
||||||||||||||||||||
mDNS Profiles
484
Technet24
||||||||||||||||||||
||||||||||||||||||||
mDNS AP
At this point, your WLC learns services from wireless devices and from wired devices; however,
mDNS is not routable. Therefore, your WLC will learn only about wired services that are in the
same subnet as your WLC’s interfaces; that is, VLANs that are “visible” to the WLC (and likely
close to your WLC, as the trend is to limit the scope of VLANs to a single or limited set of
switches). Your WLC will not learn about wired services on switches to which your APs connect, if
they are in different subnets/VLANs (and different switches) that are not Layer 2 visible to the
WLC. To enable the AP to encapsulate into CAPWAP and send to the WLC the services it detects
on its switch, enable mDNS AP.
Note
The AP will detect only wired services in its VLAN. If you want the AP to detect services in more
than one VLAN, set the AP port to trunk, with the AP intended VLAN as the native VLAN.
The AP can snoop up to 10 VLANs, so you may have to limit the number of VLANs on the AP
trunk (with the switchport trunk allowed vlan interface command), and those VLANs should also
be configured at the mDNS AP feature level, because the WLC has to understand the VLAN tags
485
||||||||||||||||||||
||||||||||||||||||||
At this point, your WLC may start to be overloaded with service announcements from wireless and
wired locations. There are a few ways to limit the amount of traffic. The first mechanism is to
ensure that the most important services are always on top (always present in the list of services,
even if the list exceeds the max number of entries on your WLC platform). This feature is called
Priority MAC. From the Controller > mDNS General page, select a service at the bottom of the
page or add a service. In the Service Detail page, at the bottom, you can associate the priority MAC
to that service, as shown in Figure 7-44.
Technet24
||||||||||||||||||||
||||||||||||||||||||
After a service is configured, it will be learned from wired/wireless. However, you can decide
whether a given service should be learned only from Wired or Wireless (or both). This is done
simply from the Controller > mDNS > General page. For each service listed, you can set the
Origin to All, Wired, or Wireless.
Note
Keep in mind that Origin works inbound. You filter if the service should be discovered from wired
sources, wireless sources, or both. Origin does not say that a service should not be advertised to
wireless, for example. To configure outbound policies, use Profiles (or policies) and associate them
to a WLAN or an interface.
If you configure a service for LSS, you apply a restriction that is wireless only (LSS does not work
for wired services). Therefore, if a service is set for LSS, you cannot configure it to be “wired
only.”
LSS
In some cases, you may want to limit mDNS exchanges to devices on a given AP (regardless of the
SSID) or a set of neighboring APs. A typical example is a large (or densely populated) classroom
with two or three APs, where iPads communicate with the local wireless Apple TV, and the like,
but should not communicate with an Apple TV on the other side of the school (typically because
there would be potentially tens of Apple TVs to choose from every time, and this would not be
practical). This type of filtering is called Location Specific Services (LSS).
LSS is also simply configured on a per service level, in Controller > mDNS > General. You can
check LSS for any service already present or that you add. When you click Apply, each service for
487
||||||||||||||||||||
||||||||||||||||||||
mDNS Policies
Filtering per location or origin is efficient in smaller networks. In larger networks, stricter policies
are required. Bonjour policies allow per service instance (MAC address) configuration that
mandates how the service instance is shared:
Service instance is shared with whom (user-id)?
Service instance is shared with which role(s) (client-role)?
What is the location allowed to access the service instance (client location)?
This configuration can be applied to wired and wireless service instances, and the response to any
query will solely be based on the policy configured for each service instance. This allows selective
sharing of service instances based on the location, user-id, or role. Because most service publishing
devices are wired, this allows filtering of wired services at par with wireless service instances.
While an mDNS profile associated with the client checks for service type being queried before
responding to the query, the access policy further allows filtering of specific service instances based
on querying client location, role, or user-id.
To configure this type of filtering, you start by creating service groups. A service group is a name
associated with a set of MAC addresses. Each MAC address is configured with a unique name,
which can be the service instance name, and the location of the MAC address for both wired and or
wireless. The location can be an AP, an AP group, or an AP location. An AP location is particularly
useful if you expect users to roam (and if no AP group matches the roaming domain). You can use
the location name (setting the same location name on multiple APs) to determine the set of APs
among which the service instance can be supported. This configuration implies that only clients
488
Technet24
||||||||||||||||||||
||||||||||||||||||||
489
||||||||||||||||||||
||||||||||||||||||||
If you configure a role or a username, the authenticating user will need to receive such an attribute.
This is done with AAA override enabled in the WLAN and an authorization profile in ISE that will
associate the user with the role name. Your ISE authorization profile can also point directly to an
mDNS profile name.
Note
For a sample configuration, see
https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/WLAN-Bonjour-DG.html.
If you do not use AAA override, you can also use local policies (in Security > Local Policies) to
identify a device type and associate an mDNS profile to that local policy. The local policy can also
target a role string obtained via AAA override.
Most of the best practice configurations are enabled by applying the Fastlane macro on an SSID.
Study what this macro configures and you will know most of the best practices for AireOS QoS.
The only exception is ACM, which should be enabled only on a case-by-case basis. In 8.3, Fastlane
enables CAC automatically (later codes do not), but you can disable ACM if needed (or asked).
Keep CAC if most of your clients are Apple and/or hard phones. Disable CAC if most of your
clients are of different categories (Windows, Android).
There is no best practice configuration for AVC or for Bonjour/mDNS. The lab questions will
dictate what should be configured and how. In the real world, AVC may have some impact on your
WLC CPU (or not!), so you should test your AVC configuration before deploying it widely.
Autonomous APs
490
Technet24
||||||||||||||||||||
||||||||||||||||||||
“Advanced features”: Apply customization parameters designed for autonomous APs and
voice traffic optimization.
DSCP to UP Mapping
The autonomous AP GUI includes a Services > QoS page, shown in Figure 7-46. You should know
its content well.
491
||||||||||||||||||||
||||||||||||||||||||
In the Cisco window, "services" tab is selected that displays the Services list in the
navigation pane. In the Content pane "QoS policies" is selected that displays the sections
"Create and Edit policy, policy name, and classifications." Under "Match Classification"
section "IP DSCP" radio button is selected for "Best Effort (selected from the spin box)."
"Apply class of service" section is shown with "Add" buttons. "IP protocol" section is
shown with "Filter" field. "Rate limiting section" shows the fields "Bits per second,
conform action, burst rate, and exceed action." "Apply policies to Interface/VLANs"
shows a table with the headers "VLAN 1, Radio0 to 802.11N to the power 2.4 GHz,
Radio1 to 11.N to the power 5 GHz, and GigabitEthernet."
On the QoS policies tab, you can create a customized mapping between wired QoS and 802.11 QoS
values. You can also associate this mapping to a rate limiting configuration.
In the GUI, create a new policy name. In the match classification area, select which DSCP value
492
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
The table for Apply policies to Interface or VLANs shows the column headers: VLAN 1,
Radio0 to 802.11 N to the power 2.4 Gigahertz, Radio1 to 802.11N to the power 5
Gigahertz, and GigabitEthernet0. Under VLAN 1, the data for the incoming signals are as
follows: data (spin box), empty, and data (spin box); Outgoing: data (spin box), empty, and
data (spin box). Under VLAN 12 the table infers the following data "Incoming, empty, real-
time (spin box), and Real-time (spin box); Outgoing, empty, real-time (spin box), and real-
time (spin box) (selected)." Apply and Cancel buttons are displayed at the bottom.
Applying the Data policy to everything VLAN 1 and the Voice policy to everything VLAN 12 is
simple and efficient.
In the context of the CCIE Wireless exam, you also need to carefully examine what you are
attempting to achieve (and what the question states). If your policy only does remarking, an
Ethernet incoming policy will ensure the correct mapping as the wired packet transits through the
AP toward any radio interface. Therefore, there is no reason to apply the policy both on the
incoming direction of the Ethernet interface and on the outgoing direction of a VLAN or radio (you
make the AP do the work twice).
The preceding holds true if your expected traffic flows with a simple structure (from wired to
wireless). However, if you expect traffic to flow from one radio to the other, then positioning the
policy at the radio outgoing direction makes more sense.
The same logic applies for the reverse direction.
In summary:
Apply the policy to both wired and wireless incoming direction if the traffic is expected to flow
between a given SSID and the wired network. Do not apply the policy to the outbound
direction on any interface.
495
||||||||||||||||||||
||||||||||||||||||||
Apply the policy to both wired and wireless outgoing directions if the traffic is expected to flow
between a given SSID and another SSID, as well as between a given SSID and the wired
network. Also, applying the policy to the incoming direction is then optional (but acceptable).
The CLI command to apply the policy follows a particular logic.
The policy is applied to either the interface level or the subinterface level (if VLANs were created).
The following example shows subinterfaces for VLAN 1 and VLAN 12 (following the GUI example
structure).
The policy is called at the subinterface level with the command service-policy and the direction:
Click here to view code image
interface Dot11Radio0.1
service-policy input Data
service-policy output Data
interface Dot11Radio1.12
service-policy input RealT
service-policy output RealT
interface GigabitEthernet0.1
service-policy input Data
service-policy output Data
interface GigabitEthernet0.12
service-policy input RealT
service-policy output RealT
You can add bandwidth control along with the remarking policy. The GUI does not let you create
both (bandwidth options with class of service mapping), but you can create a new policy that
provides bandwidth selection. You then have the option to define a rate limit value and a burst rate.
Be careful, the rate limit is in bits (binary 0 or 1) per second, burst is in bytes (octets).
In the CLI, the rate limit can be added to a marking policy or be an independent policy. Inside the
policy map, you still call the class, and then decide the rate limit with the policy command. For
example:
Click here to view code image
Class Map match-all _class_BW0
Match any
Policy-map ratelimit
Class _class_BW0
police 30000 50000 conform-action transmit exceed-action drop
496
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the Cisco window, "Security" tab is selected that displays a list in the navigation pane
where "SSID manager" is selected. The content pane lists the "Rate limit parameters" with
Limit TCP and Limit UDP sections. In the "Limit TCP" section Input check box is selected
with the rate: 4000, burst-size: 5000 (0 to 500000). In the "Limit UDP" output checkbox is
selected with the rate: 3000 and burst-size: 6000 (0 to 500000).
The CLI equivalent is done under the SSID configuration in global mode, for example:
Click here to view code image
dot11 ssid Test1
vlan 12
rate-limit tcp input data-rate 4000 burst-size 5000
rate-limit udp output data-rate 3000 burst-size 6000
497
||||||||||||||||||||
||||||||||||||||||||
Retry Options
Having different types of traffic mapped to different UPs is critical. However, you also know that
voice traffic is time sensitive. Getting statistical advantage in the medium access with UP 6 is great,
but IOS also allows you to configure two more options (that are not present in AireOS): the retry
count for each UP and the rate shifting options for these UPs. AireOS uses an internal timer logic
for voice that can be configured in the EDCA parameter page (Low Latency MAC—this feature
enables a 30 ms timer that drops voice frames that stay in the AP buffer for more than that
duration).
This option was not covered in the AireOS section because it is not best practice. (Do not use it
unless you are in a lab and someone asks you to turn it on.) In most cases, it is better to let the end
device manage its buffer than to decide at the AP level whether the device buffer is about to get
empty.
In the IOS world, an equivalent parameter exists and is called Low Latency Queue (LLQ). This is
not something you would activate in the real world unless you are addressing a very specific use
case. The lab is of course a different environment in that it always asks you to solve a very specific
use case.
LLQ means that whenever a packet gets in the AP buffer, it will always be sent first (before
packets in other queues are dequeued), giving delay-sensitive data preferential treatment over other
traffic.
This means that you can prioritize traffic on an IOS AP with three methods:
1. With the policy map method, you may just tag, which says “this packet is urgent” but does not
apply any priority per se.
2. There is a QoS Elements for Wireless phones option (discussed next) that prioritizes any voice
packet regardless of any other consideration. This is an LLQ “by nature,” without any upper
limit.
3. With the LLQ option queue configured here, you define how many times the AP should try to
send each voice packet, and at what speed, before giving up and trying the next packet.
LLQ is configured in Services > Stream > Radio0 or Radio1.
Set Cos 6 (Voice) to Low Latency Queue, as shown in Figure 7-50.
498
Technet24
||||||||||||||||||||
||||||||||||||||||||
499
||||||||||||||||||||
||||||||||||||||||||
For example, in Figure 7-50, if your AP to client RSSI level is good enough to try 36 Mbps, the AP
will try 24 Mbps (first nominal rate at or below the client possible rate), then revert to 12 Mbps if
24 Mbps fails.
Suppose that 24 Mbps and 6 Mbps are set to Nominal, and 12 Mbps is set to Non-nominal (other
rates are disabled). The AP would try 24 Mbps first, then 6 Mbps, then 12 Mbps if none of the
nominal rate attempts were successful.
So good practices are to set the rates you want to use as Nominal, then set one low rate as Non-
nominal, so that the AP has a plan B in case all possible nominal rates fail. Disable all other slow
rates.
In the CLI, these elements are configured at radio level. For example:
500
Technet24
||||||||||||||||||||
||||||||||||||||||||
EDCA Parameters
Configuring bandwidth control is uncommon because the queuing mechanisms on the radio
interface use 802.11e parallel queuing with CW and other 802.11-specific parameters. Attempting
to use wired-type bandwidth control with policing or shaping is often seen as an attempt to square
circles, using tools that are not adapted to the constraints of 802.11 transmission mechanisms.
It is, however, more common to tune the 802.11 parameters for transmission control for each QoS
501
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Advanced Features
IOS also includes customizations intended to improve the performance of voice traffic. Most of
them are located in the Services > QoS > Advanced tab.
Prioritizing voice traffic over a wireless link on autonomous APs can be done in three ways. The
first one is to create a class map, a policy map, and a service policy, then set a higher bandwidth or
priority level to voice traffic. This is what the previous Policy section was about. But in an
autonomous AP (remember, a Layer 2 bridge), applying a QoS tag (DSCP, CoS, or 802.11e) only
partially solves the problem. The DSCP or CoS tag will simply label the frame as urgent or not.
Putting the frame in an 802.11e category based on its tag (EF in CoS 6, for example) helps, because
each queue is treated differently in the AP buffer, and the voice queue is statically prioritized over
the other queues. If there are too many voice packets, using CAC can also prevent having voice
packets starve the other queues.
But if there are many “other types” of packets, and few voice packets in between, putting the voice
frame in UP6 may not be enough. Your voice packets may be delayed because other larger packets
are filling up the AP queues. To enhance the prioritization, you may need to add another feature
that would always prioritize voice packets. This feature is called QoS Element for Wireless Phones
and can be found in Services > QoS > Advanced, as shown in Figure 7-52.
504
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the Cisco window, "services" tab is selected that displays the list of services in the
navigation pane where "QoS" is selected. In the content pane "Advanced" tab is selected
that displays the sections IP phone, IGMP snooping, AVVID priority mapping, and WIFI
Multimedia. Under IP Phone section, "QoS element for wireless phones" field is shown
with a radio button selected for "Enable" and a checkbox selected for "Dot11e." Under
"ICMP snooping" field, "Enable" radio button is selected for Snooping helper. Under
"AVVID Priority mapping," "No" radio button is selected for "map ethernet packets with
Cos 5 to Cos 6." Under "Wifi Multimedia (WMM)" the radio buttons "Radio0 to 802.11N
to the power 2.4 Gigahertz and Radio1 to 802.11N to the power 5Gigahertz" are selected
under Enable radio interfaces.
Enabling QoS Element for Wireless phones generates two behaviors:
The AP prioritizes voice packets over the wireless links, regardless of any QoS configuration.
The AP sends in its beacon an additional information element called QoS Basic Service Set
Load Information Element, or QBSS Load IE. This information element mentions how many
clients are associated to the SSID, and what the AP utilization percentage is. Roaming devices
can use this information to decide which AP is the best candidate to join (having more space
and fewer clients). This information can be sent in a Cisco-proprietary and pre-802.11e way
(by just checking QoS Element for Wireless Phones), or using the IEEE 802.11e format (by
also checking the Dot11e check box).
505
||||||||||||||||||||
||||||||||||||||||||
506
Technet24
||||||||||||||||||||
||||||||||||||||||||
In the Cisco window, "Services" tab is selected that displays a list of services in the
navigation pane where "ARP Caching" is selected. The content pane shows the services of
the "Client ARP Caching" with the radio button selected for "Enable" and a checkbox
selected for "Forward ARP requests to radio interfaces when not all client IP addresses are
known." "Apply and Cancel" buttons are displayed at the bottom.
In the CLI, this is also a global command:
Click here to view code image
Ap(config)# dot11 arp-cache optional
The optional keyword is the forwarding to radio interface optional part.
IOS AP configuration for supporting application services sometimes looks like a disconnected
collection of items, without clear flow. The reason may be that autonomous APs are Layer 2
bridges. They are not intended to collect, store, examine traffic, and then decide the best fate and
path based on the traffic type. They are intended to convert 802.11 headers into 802.1 headers and
back. Anything above is optional. In a lab, the “above” will match the question you are asked. In
the real world, there are a few items that are considered as best practices:
Keep WWM to enabled (in Services > QoS > Advanced).
Set the AVVID mapping policy (same location).
Enable ARP caching (in Services > ARP Caching).
If you use voice, set the Access Categories for the matching radio to voice optimized of
507
||||||||||||||||||||
||||||||||||||||||||
Wired Configuration
The CCIE Wireless exam tests your knowledge of Wi-Fi. However, it would be an illusion to think
that the network you care about (and therefore your skills) stop at the AP or WLC level. Clearly,
there would be, in any network, a large number of other specialists to take over where you left off
and configure routing, wired QoS, Unified Communications, deep Security, and so on. However,
you should not think that there is no reason for you to know anything about these fields. In fact,
you should aspire to be independent, face any network on your own, and survive any configuration
request, even if the request has an impact on the wired infrastructure and no campus LAN
Switching specialist is there to help you.
In the application services field, this autonomy implies being able to configure basic QoS on a
switch. Such an ability covers two fields:
The ability to use DSCP or 802.1p when making a switching decision
The ability to create marking and queueing policies on a switch
Most switches receive traffic on access ports and trunk ports. On access ports, QoS is expressed
only in the Layer 3 DSCP field. Trunk ports can receive traffic that includes an 802.1Q header,
which includes an 802.1D/802.1p Layer 2 QoS value. You can configure the switch to use the
Layer 3 DSCP value or the Layer 2 CoS value, to decide the fate of the incoming packet. The best
practice, in the context of wireless, is to use DSCP, because it expresses the end-to-end intent of
the packet (refer to the first part of this chapter). Although a switch is a Layer 2 device, most
switches can work with Layer 3 and recognize DSCP. The value you use (DSCP or CoS) is set by
the trust value:
Click here to view code image
508
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
QoS Policies
Making sure that you trust DSCP is the first QoS task on your switches. The other task is setting
rules and policies, just like you did on the autonomous AP.
The logic is similar to that of the autonomous AP CLI. You create class maps that target specific
traffic (based in existing marking or source/destination pairs, for example), the policy maps that
decide what should happen to the targeted traffic. You then apply these policies to interfaces.
Class Maps
510
Technet24
||||||||||||||||||||
||||||||||||||||||||
Policy Maps
After you have class maps, you can create policy maps that call each class map in turn and decide
the QoS marking for traffic in that class. For example:
Click here to view code image
sw(config)# policy-map VOIP3
sw(config-pmap)# class voice_ports
511
||||||||||||||||||||
||||||||||||||||||||
Service Policy
After the various policy maps are created, you apply them to the interfaces of your choice. For
example:
Click here to view code image
sw(config)# interface g1/0/1
sw(config-if)# service-policy output VOIP3
Notice that the span of possibilities will depend on your switch platform. In general, you can create
remarking policies inbound or outbound, although it makes more sense to remark traffic as you
receive it (inbound), instead of keeping the wrong marking as the traffic traverses your switch, and
only caring about making the marking right when traffic leaves your switch. This is a general
recommendation, but the CLI will allow you to remark wherever you want (on most platforms).
You can also set bandwidth limitations with police, bandwidth, shaping, and many other commands.
The details of which option is best, based on the intent of your configuration, is more in the realm
of QoS and voice specialist than in that of a wireless expert. However, you should keep in mind that
bandwidth control usually makes sense only outbound. When traffic reaches your switch you want
to receive it and mark it properly, but it is too late to decide how much of that traffic you should
accept (you are on the passive, receiving side of the link). It is only when you send traffic outbound
that you should decide how much should be sent, and this is where bandwidth limiting
configurations make sense.
Summary
The first part of this chapter is key to understanding the multiple concepts behind application
services configuration. Keep in mind that QoS can be expressed at Layer 2 or Layer 3. Layer 3
QoS, with DSCP and PHB, expresses the end-to-end QoS intent for the target traffic, whereas
Layer 2 QoS expresses the local QoS intent, based on the local medium constraints and
characteristics. A higher QoS label value typically reflects a higher sensitivity to delay, jitter, and
losses. RFC 4594 (and a few others) define the common basis to classify various types of traffic
and express their sensitivity to loss, jitter, and delay. On a WLC, traditional marking relied on Wi-
Fi Layer 2 marking translated to (and from) Ethernet Layer 2 marking. However, the current
recommendation is to use DSCP instead.
512
Technet24
||||||||||||||||||||
||||||||||||||||||||
513
||||||||||||||||||||
||||||||||||||||||||
Code Snippets
Code Snippets
Many titles include programming code or configuration examples. To optimize the
presentation of these elements, view the eBook in single-column, landscape mode and
adjust the font size to the smallest setting. In addition to presenting code and
configurations in the reflowable text format, we have included images of the code that
mimic the presentation found in the print book; therefore, where the reflowable format
may compromise the presentation of the code listing, you will see a “Click here to view
code image” link. Click the link to view the print-fidelity code image. To return to the
previous page viewed, click the Back button on your device or app.
514
Technet24
||||||||||||||||||||
||||||||||||||||||||
Code Snippets
515
||||||||||||||||||||
||||||||||||||||||||
Code Snippets
516
Technet24
||||||||||||||||||||
||||||||||||||||||||
Code Snippets
517
||||||||||||||||||||
||||||||||||||||||||
Code Snippets
518
Technet24
||||||||||||||||||||
||||||||||||||||||||
Code Snippets
519
||||||||||||||||||||
||||||||||||||||||||
Code Snippets
520
Technet24
||||||||||||||||||||