CCNP WIRELESS 300-365 WIDEPLOY STUDY MATERIAL: PASSING SCORE IS 818
CONTENTS
1: IMPLEMENT QOS FOR WIRELESS APPLICATIONS: 13% WEIGHTING ON THE EXAM .......................................................... 3
2: IMPLEMENT MULTICAST OVER WIRELESS: 13% WEIGHTING ON THE EXAM .................................................................. 12
3: IMPLEMENT HIGH DENSITY: 13% WEIGHTING ON THE EXAM ......................................................................................... 17
4: DESIGN AND DEPLOY WIRELESS INFRASTRCUTURE FOR MOBILTY: 18% WEIGHTING ON THE EXAM ............................. 18
5: IMPLEMENT CISCO MSE ARCHITECTURE: 12% WEIGHTING ON THE EXAM..................................................................... 32
6: DESIGN AND IMPLEMENT FLEXCONNECT ARCHITECTURE: 12% WEIGHTING ON THE EXAM ......................................... 45
7: IMPLEMENT CONTROLLER & AP HIGH AVALIABILITY: 10% WEIGHTING ON THE EXAM .................................................. 53
8: WIRELESS BRIDGING (MESH): 10% WEIGHTING ON THE EXAM ....................................................................................... 60
ACRONYMS:
DCF: Distributed Coordination Function
IFS: Inter-Fame Spacing
AIFSN: Arbitration Inter-Frame Spacing
CW: Contention Window
EDCA: Enhanced Distributed Channel Access
WMM: Wi-Fi Multi Media
CAC: Call Admission Control
CAPWAP: Control and Provisioning of Wireless Access Points
SSO: Stateful Switch Over
LAG: Link Aggregation
CCX: Cisco Compatible Extensions
CCKM: Cisco Central Key Management
PKC: Proactive Key Caching
OFDM: Orthogonal Frequency-Division Multiplexing
EoIP: Ethernet Over IP
RAP: Root Access Point
MAP: Mesh Access Point
WGB: Work Group Bridge
COS: Class of Service (Layer 2 Frames)
DSCP: Differentiated Services Code Point (Layer 3 Packets)
IGMP: Internet Group Management Protocol
mDNS: Multicast Domain Name System
MGID: Multicast Group ID
PORT NUMBERS:
CAPWAP CONTROL PATH PORT: UDP 5246
CAPWAP DATA PATH PORT: UDP 5247
BONJOUR mDNS PORT: UDP 5353 IP: 224.0.0.251
WLC MOBILITY PORT: UDP 16666
PRIME TO MSE: SOAP / XML SSL 443 (Credentials)
NMSP PORT: TCP 16113 SSL (Credentials Required)
AIR QUALITY INDEX (AQI) VALUES:
AQI HIGH: 60
AQI MED: 50
AQI LOW: 35
-----------------------------------------------------------------------------------------------------------------------------------------------------------
1: IMPLEMENT QOS FOR WIRELESS APPLICATIONS: 13% WEIGHTING ON THE EXAM
The Wi-Fi Multi Media (WMM) is a set of feature components of the 802.11e draft. These make use of EDCA. Cisco
products support the WMM feature set.
NOTE: The WMM and IEEE 802.11e classifications are different from the classifications recommended and used in Cisco
networks, which are instead based on IETF recommendations. The primary difference in classification is the demoting of
voice and video traffic to 5 and 4, respectively.
NOTE: WLAN client support for WMM does not mean that the client traffic automatically benefits from WMM. The
applications looking for the benefits of WMM assign an appropriate priority classification to their traffic and the
operating system needs to pass that classification to the WLAN interface. In purpose-built devices, such as VoWLAN
handsets, this is done as part of the design. However, if implementing on a general-purpose platform such as a PC,
application traffic classification and OS support must be implemented before the WMM features can be used to good
effect.
WMM ACCESS CONTROL QUEUES:
There are four separate queues used by WMM, one for each of the Access Categories (CA). Each of these queues
contends for the wireless channel in a similar manner to the DCF mechanism. Each of these queues has their own
different inter-frame space, TX-OP, CWmin, and CWmax values.
Here are the default settings (AIFSN, CW_Min, CW_Max, X value, TX-OP, AIFS) of those four access categories:
If more than one frame from different access categories collide internally before being transmitted over the air, the
frame with the higher priority is sent, and the lower priority frame adjusts its back-off parameters as though it had
collided with a frame external to the queuing mechanism. This system is referred to as enhanced distributed channel
access (EDCA).
INTER-FRAME SPACING NON-QOS | STANDARD DCF:
As part of using wireless QoS, the WLC will use the SIFS (Short Interframe Spacing) mechanism.
NON-QOS WIRELESS INTER FRAME SPACING:
SIFS: (SHORT INTER-FRAME SPACING) 802.11
SIFS: 802.11b/g/n (2.4 GHz) = 10µS
SIFS: 802.11a/n/ac (5 GHz) = 16µS
INTER-FRAME SPACING FOR QOS | EDCA:
 The number of slot times used in the AIFS is called the Arbitration Inter-Frame Space Number (AIFSN)
 The Arbitration Inter-Frame Spacing (AIFS) specifies a wait time for data frames. The wait time is measured in slots.
Valid values for AIFS are 1 through 255
 The AIFS shall be used by a QoS STAs to transmit all data frames (MPDUs), all management frames (MMPDUs)
1:) Voice & Video category uses 2 Slot-Times
2:) Best Effort category uses 3 Slot-Times
3:) Background category uses 7 Slot-Times
NOTE: To be compliant with both standards, the Cisco Unified Wireless solution performs a conversion between the
various classification standards when the traffic crosses between the wireless / wired boundary.
NOTE: Obviously the 8 values of CoS cannot exactly map to 64 DCSP values so that's what the above table outlines.
TRANSMISSION OPPORTUNITY:
The term TX-OP is used in wireless networks that support the IEEE 802.11e Quality of Service standard. Used in
both EDCA and HCCA modes, the TX-OP is a time interval in which clients are permitted to transfer a series of frames
instead of one frame at a time. This is also known as “Contention Free Burst (CFB)”. This is only for clients that support
QoS.
A TX-OP client will have unfettered access to the channel for data transmission. During a TX-OP transmission event, only
the data that makes up a CFB and the ACK for that data may access the channel.
The 802.11e standard defines a default TX-OP limit value for each Access Category (AC), but values can be configured on
AP. The TX-OP limits are set in intervals of 32µs (microseconds). A TX-OP is defined by a start time and a maximum
duration. The TX-OP Limit maximum allowed value is 65535.
Default TX-OP is 47 intervals of 32µs for AC_VO (47×32=1504µs) for OFDM and it is 94 intervals of µs for AC_VI
(94×32=3008µs).
NOTE: For AC_BE & AC_BK always TX-OP set to 0, in other words those traffic categories always have to send one frame
at a time (no CFB).
QOS PORT CONFIGURATION EXAMPLES:

Network Upstream is traffic from the AP to the WLC or the LAN (FLEX)

Network Downstream is traffic from the WLC or LAN(FLEX) to the AP

Radio Upstream is traffic from the Wireless Client to the AP

Radio Downstream is traffic from the AP to the Wireless Client
AP (LOCAL MODE) SWITCHPORT CONFIG:
Use "mls qos trust dscp" so that the switch will trust the DSCP marking on the CAPWAP packets that are sent to it from
the AP (Local Mode AP). There are no CoS marking on the CAPWAP frames coming from the AP as local mode AP’s on an
access switch port.
AP (FLEXCONNECT MODE) SWITCHPORT CONFIG:
1): Use "mls qos trust dscp" on FlexConnect AP ports, if you want the switch to preserve the network upstream (TO LAN
/ WLC) DSCP markings for a locally switched WLAN / SSID’s. i.e client traffic from the AP to the rest of the wired LAN.
This will trust all DSCP marked traffic which is on both data and CAPWAP management from the AP itself. However,
when changes are made to the WLAN QoS Policy on the WLC (Platinum, Silver, Best Effort), it will only change the CoS
markings coming from the AP to the wired network, so your QoS profiles changes will have no effect if you are trusting
DSCP.
If the WLAN is centrally switched then you will also need to trust DSCP as the markings on the CAPWAP headers will
need to be honoured.
2): Use "mls qos trust cos" on FlexConnect AP ports, if you want the switch to override the 802.1p to network upstream
(TO WLC) DSCP markings for a locally switched WLAN / SSID’s. i.e client traffic from the AP to the rest of the wired
network.
This will make sure that when changes are made to the QoS policy on the WLAN that those markings are trusted by the
switch which that AP connects too and are preserved accordingly.
WLC SWITCHPORT CONFIG:
WLC QoS can be to either trust the DSCP or trust CoS of the traffic coming from the WLC.
1): If using a QoS Profile with wired qos protocol enabled, use "mls qos trust cos" on the trunk port to the WLC if you
want the outgoing CAPWAP traffic to reflect what QoS Profile CoS setting has been set. Additionally, this allows you to
override the DSCP on the outgoing network upstream traffic via the QoS Profile setting. This is considered Cisco best
practise.
Use "mls qos trust dscp" on the trunk port to the WLC if you want CAPWAP traffic CoS/DSCP to reflect the original DSCP
setting and also if you want to preserve the DSCP marking on the outgoing network upstream traffic from the AP.
2): If using a QoS Profile without wired qos protocol always use "mls qos trust dscp" on the WLC trunk port.
NOTE: With either "mls qos trust cos" or "mls qos trust dscp" on the trunk port to the WLC, the downstream WMM
radio traffic will be marked down to whatever the wired qos protocol setting is set to.
STANDARD CSO TO DSCP MAPPING:
Switches use an internal DSCP values when moving traffic through the switch. However, if the marking received is a CoS
marking the switch then needs to derive a DSCP value from this value which is what the QOS map cos-dscp is used for.
When WMM audio traffic arrives with a CoS of 6 at the AP, and the AP automatically performs a CoS-to-DSCP mapping
for this traffic based on a CoS of 6. If the CoS value in the WLC configuration is set to a value less than 6, this changed
value is used by the WLAN QoS profile at the AP to set the maximum CoS marking allowed and therefore which WMM
admission control (AC) to use.
mls qos map cos-dscp 0 8 16 24 32 46 48 56
CoS value 0 = DCSP 0
CoS value 1 = DCSP 8
CoS value 2 = DSCP 16
CoS value 3 = DSCP 24
CoS value 4 = DSCP 32
CoS value 5 = DSCP 46
CoS value 6 = DSCP 48
CoS value 7 = DSCP 56
DSCP TO IP PRECEDENCE MAPPING:
DSCP Value
Decimal Value (DSCP) Layer 3
COS Layer 2
Equivalent IP Precedence Value
000 000
0
Default
001 000
8
CS1
1
010 000
16
CS2
2
011 000
24
CS3
3
100 000
32
CS4
4
101 000
40
CS5
5
101 110
46 (EF)
CS5
5
110 000
48
CS6
6
111 000
56
CS7
7
TSPEC ADMISSION CONTROL:
Traffic Specification (TSPEC) allows an 802.11e client to signal its traffic requirements to the AP. In the 802.11e MAC
definition, two mechanisms provide prioritized access. These are the contention-based EDCF option and the controlled
access option provided by the transmit opportunity (TX-OP).
When describing TSPEC features where a client can specify its traffic characteristics, it is easy to assume that this would
automatically result in the use of the controlled access mechanism, and have the client granted a specific TX-OP to
match the TSPEC request. However, this does not have to be the case; a TSpec request can be used to control the use of
the various ACs in EDCF.
Before a client can send traffic of a certain priority type, it must have requested to do so via the TSpec mechanism. For
example, a WLAN client device wanting to use the voice AC must first make a request for use of that AC. Whether or not
AC use is controlled by TSpec requests is configurable with voice and video ACs controlled by TSpec requests, and besteffort and background ACs can be open for use without a TSpec request.
The use of EDCF ACs, rather than the 802.11e Hybrid Coordinated Channel Access (HCCA), to meet TSpec requests is
possible in many cases because the traffic parameters are sufficiently simple to allow them to be met by allocating
capacity, rather than creating a specific TX-OP to meet the application requirements.
NOTE: Both Cisco 7920 Phones and Nokia Phones do not support TSPEC.
WMM / QoS PROFILE MAPPINGS:
With WMM profiles such as (platinum, gold, silver, bronze), if you set a silver profile on a WLAN, clients can send
background traffic or best effort traffic but are not allowed to send voice or video classes of traffic. If voice or video is
sent, they are treated like best effort instead. It basically sets the upper limit for Qos markings.
Access Class
Quality of Service
WMM Values (Wireless Side)
Cisco-Translated CoS values (Wired Side)
Voice
WMM Platinum
802.11e 6
802.1p | COS 5
Video
WMM Gold
802.11e 5
802.1p | COS 4
Best Effort
WMM Silver
802.11e 0
802.1p | COS 0
Background
WMM Bronze
802.11e 1
802.1p | COS 1
Typically voice traffic is tagged as CoS 5 over a wired network, and COS 6 over the air with WMM/802.11e. This is often
causes confusion between the 802.1p and the WMM standards. Some vendor’s actually break the 802.11e/WMM IEEE
standard as they tag voice as COS5 over the air such as (Microsoft with Lync).
This effectively is using the 802.1p table instead of 802.11e table for over the air traffic markings. This is something to
be aware of as Cisco still respects the 802.11e standard and tags voice as COS 6 over the air. This is another reason to
trust DSCP over CoS.
NOTE: If the WLAN is configured to trust CoS rather than DSCP at the network connection end to the WLC, the CoS value
is used for the DSCP of the CAPWAP packets received by the AP; and eventually the WMM classification and queuing for
WLAN traffic. This is because the WLAN WMM classification of a frame is derived from the DSCP value of the CAPWAP
packet carrying that frame.
Another role of WMM profiles is to define the tag of non-QoS traffic. If WMM is set to allowed, clients are still allowed
to send non-QoS frames. Do not confuse the two different situations:

If a laptop supports WMM (as the vast majority of laptops do) and sends QoS data frame, it uses a tag of 0 if it is
not tagging traffic.

If a laptop does not support WMM and sends simple data frames with no QoS field, the WLC translates those data
frames into the QoS profile. For example, data frames are translated as voice markings if you configure the profile
for platinum.
QoS profiles let you take the WMM values used in the wireless space and translate them into QoS COS markings on a
wired network. The configuration on the WLC uses the 802.11e-recommended mappings which are how WMM is
defined, such that Voice = Platinum = 6, Video = Gold = 5, Best Effort = Silver = 3, Background = Bronze = 1.
On the wired side, Cisco routers and switches can operate on DSCP at layer 3 or CoS markings at layer 2. The CoS
markings are present in the 802.1p/q header that is added to packets in order to mark the VLAN to which the packet
belongs. This 802.1q tag is 16 bits long; 12 bits are used for the VLAN ID (0 through 4095), one bit is not used, and three
bits are used for CoS markings (0-7).
Because CoS values 6 and 7 have special significance on the wired network, Cisco does not send out the WMM values
defined as 6, 5, 3, and 1 for platinum, gold, silver, and bronze respectively. Instead, Cisco translates them into the CoS
values of 5, 4, 0, and 1 etc which follows the 802.1p standard as shown in above’s table.
Wireless traffic that is associated with a higher priority QoS profile is given a higher priority tag on the wired side. The
CoS value assigned based on the WMM to 802.11e to 802.1q marking is maintained by both the AP and the WLC so that
the Control and Provisioning of Wireless Access Points (CAPWAP) packets are given the same level of wired QoS as the
packet, once the CAPWAP header is stripped off by the WLC and sent on to the wired network with the correct masking.
Similarly, traffic from the wired network that is in route to a wireless client has a CoS value associated with it that Cisco
copies to the CAPWAP packets that go to the AP. The AP then uses the CoS value in order to determine the proper
WMM queue to use.
LOAD-BASED CALL ADMISION CONTROL (CAC):
Load-Based CAC is dynamic with regard to the algorithm used to decrement Medium Times from the total that is
available. It takes into consideration different metrics, such as AP Load, Co-channel Interference, SNR, etc and will
therefore yield different results when tested.
Cisco states that it is very difficult to yield consistent results as RF fluctuates and changes within the given environment.
Results tend to vary from one cell area to another and even in cell areas that yield the same signal strength.
Overall, LB-CAC does yield a greater number of calls per AP due to the mechanisms it uses to decrement the available
Medium Times. Remember, with Static CAC, a bi-directional RTP stream decrements a fixed value of 1076 MT's from the
available bandwidth, while LB-CAC will factor in other variables and might only decrement 700 or 800 medium times per
call.
STATIC CALL ADMISION CONTROL (STATIC CAC):
Static / Bandwidth CAC is based on a percentage of the total Medium Times available and is measure in increments of
32 microseconds.
Following Cisco typical VoWLAN best practises, a single uni-directional RTP stream will utilize 538 Medium Times, or
1076 Medium Times per call. An AP supports a total of 31,250 Medium Times, which is defined in the 802.11e standard
and is an RF measurement used by TSPEC for Admissions Control.
In a Static CAC configuration, the Medium Times are multiplied by the Max RF bandwidth and Reserved Roaming
Bandwidth and divided by the number of calls that are made against a single AP during Association.
For example, if Static CAC has been configured using default settings, codecs and data rates in accordance with VoWLAN
Design and Deployment Best practices, the formula to calculate the total number of calls is as follows:

If each uni-directional RTP stream utilizes 538 Medium Times, you would multiply that times 2 to determine to
the total MT's per call. In this example, it is 1076 MTs per call.
1. 31250 (Medium Times) * Configured Max RF Bandwidth \ 100 = (maxBw)
2. (maxBw) * Configured Reserved Roaming Bandwidth \ 100 = (roamBw)
3. The (roamBw) should then be subtracted from the (maxBw), and then divided by 1076 yielding the total number
of calls allowed on the VoWLAN.
To enable or disable bandwidth-based voice CAC for the 802.11a or 802.11b/g network by entering this command:
config {802.11a | 802.11b} cac voice acm {enable | disable}
CAC SCENARIO:
792xG Series wireless IP Phone is on AP1, Controller 1, and then roams to AP2 Controller 2. In a situation where there is
not enough bandwidth available over the air on the Wireless LAN Controller where the phone is roaming to, a “Status
code 202” error is sent to the phone resulting in a “Network Busy” message. The phone will then make an effort to roam
to another AP with the strongest signal (usually the AP it was most recently connected to), but will perform a full Reauth. This scenario will also cause the call to be dropped.
NOTE: Call capacity planning is essential and should be performed during an initial site survey and followed up by a post
audit.
The fundamental idea behind call capacity planning is to ensure that users do not saturate a single AP, causing CAC to
deny access to network resources. The debug cac all enable command can be used to test and isolate if the scenario
outlined above is the root cause of your problems.
AVC / NETFLOW ON PRIME:
The hardware requires for AVC support on the wireless controllers is as follows:




AVC works on traffic from Cisco APs in “Local Mode”, FlexConnect and OEAP traffic.
AVC is based on port, destination and heuristics which allows deep visibility.
AVC looks into the initial setup of the client flow (first 10-20 packets) thus load on the controller system is minimal.
Available for all current generation Cisco controllers supporting v7.4 - Cisco 2504, 5508, WiSM2, Flex 7500 & 8500
To ensure that Prime Infrastructure can make use of NetFlow data, your network devices must:


Have NetFlow enabled on the interfaces that you want to monitor.
Export the NetFlow data to the Prime Infrastructure server and port
Use the following commands to enable NetFlow on Cisco IOS devices:


Device(config)# interface gi0/0/0
Device(config)# ip route-cache flow
Once NetFlow is enabled on your devices, you must configure exporters to export NetFlow data to Prime Infrastructure.
For example, as per below:



Device(config)# ip flow-export version 5
Device(config)# ip flow-export destination PRIME-IP-ADDRESS PRIME-PORT
Device(config)# ip flow-export source INTERFACE-NAME
NOTE: The default interface that Prime Infrastructure server is listening for NetFlow data is 9991. Also, INTERFACE-NAME
is the interface sending the NetFlow data and will cause the source interfaces IP to be sent to Prime.
QBSS (QoS BASIC SERVICE SET):
The QoS Enhanced Basis Service Set (QBSS) information element (IE) enables an AP to communicate their channel usage
to wireless devices. Because AP’s with high channel utilization might not be able to handle real-time traffic effectively,
the 7921 / 7920 phones uses the QBSS values to determine if they should associate to another AP or not.
You can enable QBSS in these two modes:
• Wi-Fi Multimedia (WMM) mode, which supports devices that meet the 802.11E QBSS standard (i.e Cisco 7921 Phones)
• 7920 support mode, which supports Cisco 7920 IP Phones on your 802.11b/g network. However, the 7920-support
mode has two sub options:
1. Support for 7920 phones that require call admission control (CAC) to be configured on and advertised by the
client device (these are typically older 7920 phones).
2. Support for 7920 phones that require CAC to be configured on and advertised by the access point (these are
typically newer 7920 phones) When access point-controlled CAC is enabled, the access point sends out a Cisco
proprietary CAC Information Element (IE) and does not send out the standard QBSS IE.
NOTE: When access point-controlled CAC is enabled, the access point sends out a Cisco proprietary CAC Information
Element (IE) and does not send out the standard QBSS IE.
To configure QBSS follow the below process:
Step 1: Choose WLANs to open the WLANs page.
Step 2: Click the ID number of the WLAN for which you want to configure WMM mode.
Step 3: When the WLANs > Edit page appears, choose the QoS tab to open the WLANs > Edit (Qos) page.
Step 4: From the WMM Policy drop-down list, choose one of the following options, depending on whether you want to
enable WMM mode for 7921 phones and other devices that meet the WMM standard:



Disabled—Disables WMM on the WLAN. This is the default value.
Allowed—Allows client devices to use WMM on the WLAN.
Required—Requires client devices to use WMM. Devices that do not support WMM cannot join the WLAN.
Step 5: Select the 7920 AP CAC check box if you want to enable 7920 support mode for phones that require access
point-controlled CAC. The default value is unselected.
Step 6: Select the 7920 Client CAC check box if you want to enable 7920 support mode for phones that require clientcontrolled CAC. The default value is unselected. Note You cannot enable both WMM mode and client-controlled CAC
mode on the same WLAN.
Step 7: Click Apply to commit your changes.
Step 8: Click Save Configuration to save your changes.
2: IMPLEMENT MULTICAST OVER WIRELESS: 13% WEIGHTING ON THE EXAM
IP multicast is a delivery protocol used to deliver data to a group of destinations. It uses the most efficient strategy to
deliver the information over each path within the network. It sends only one copy of the information at each hop on the
network, creating copies only when the links to destinations splits.
Typical networks applications use unicast packets i.e., from one source to one destination. However, when multiple
receivers require the same data such as a video conference webinar, replicating the data from the source to all the
receivers as individual unicast packets increases the network load and is very inefficient.
IP multicast enables efficient transfer of data from a source to a dynamically formed set of receivers.
NOTE: If your network does not support multicast, the controller will use the unicast packet forwarding mechanism. IP
multicast is typically used today for one-way streaming media, such as video to large groups of receivers or media
streamers.
NOTE: FlexConnect AP’s only support Unicast Mode. If a multicast packet is received on a WLAN it will just encapsulate it
in a CAPWAP frame and send it to the WLC which will handle it as per normal.
WLC MULTICAST MODES:
For WLC’s there are two modes of multicast modes. These are listed below:
Multicast-Unicast Mode:
In this mode the WLC will forward all multicast traffic it received on the local LAN connection to all the AP’s that are
associated to it. It does this by simply making copies of the multicast packet and then sends it individually to each of the
AP’s that are associated to it.
NOTE: This mode does create a lot of overhead on the WLC as it needs to replicate multicast packets for each of the AP’s
that are associated to it causing high CPU utilization. Also, it does floods the network with a large number of duplicate
unicast packets on the network.
Multicast-Multicast Mode:
In this mode the WLC will instead of coping each of the multicast packets that it receives on the wired and sending them
to each of the AP’s as unicast packets, it will instead send them to the multicast packet to the CAPWAP Multicast Group.

The controller will be seen as the source for the CAPWAP Multicast Group and the APs associated to it become the
multicast receivers.

AP’s that are associated to the WLC with Multicast-Multicast mode enable will send an IGMP join request to join
the CAPWAP Multicast Group and will start receiving multicast traffic after joining.

The source IP address for the CAPWAP Multicast Group is the WLC’s management interface IP address.

When the WLC receives a multicast packet from any of the local VLANs, it transmits the packet to the CAPWAP
Multicast Group via the management interface with best effort QoS classification. This Qos is not configurable.

If more than one WLAN is associated to the VLAN interface where the original multicast packet was sourced from
on the wired site, the AP will transmit the multicast packet over each WLAN and if that WLAN has both radios
enabled for it, both radios as well.

AP’s that are associated to a CAPWAP Multicast Group might see other packets for other CAPWAP Multicast Groups
from other WLC’s, however it will only accept IGMP queries from the WLC that it is currently associated too.
If the multicast packet is coming from a wireless client, the AP will encapsulate that multicast packet in CAPWAP and
send it as unicast to the WLC via the CAPWAP Data control path.
The controller makes two copies of this received multicast packet. One copy is sent out the respective VLAN of which
the WLAN client resides on, thus enabling receivers on the wired LAN to receive the multicast stream.
The second copy of the packet is CAPWAP-encapsulated and is sent to the CAPWAP Multicast Group also the other
wireless clients on the same WLAN may receive the multicast stream etc.
IGMP:

The WLC sends three queries in one timeout value at an interval of timeout / 3 to see if any clients exist for a
particular multicast group. If the WLC does not receive a response through an IGMP report from the client, the
controller times out the client entry from the MGID table.

When no clients are left for a particular multicast group, the controller waits for the IGMP timeout value to expire
and then deletes the MGID entry from the controller.

The controller always generates a general IGMP query (that is, to destination address 224.0.0.1) and sends it on all
WLANs with an MGID value of 1.
IGMP SNOOPING:
The IGMP snooping examines IGMP reports from all the wireless clients who request traffic from the multicast group.
The WLC will analyse these reports and will create a unique MGID for each multicast group and vlan number.
This report will have a source address as the interface address of the respective VLAN. An AP MGID table is created on
the WLC for all AP’s that are associated with it along with their client mac addresses.
By default, without IGMP snooping enabled in Multicast-Multicast mode, the WLC will forward all multicast traffic to the
CAPWAP Multicast Group but when IGMP snooping is turned on, it will only forward multicast traffic to certain AP’s that
have clients on the respective WLAN. Which AP’s is learnt from the IGMP reports and maintained in the AP MGIP table.


Layer 3 Multicast packets are forwarded with a MGIF that is unique for the ingress vlan and the multicast group.
Layer 2 Multicast is forwarded with an MGID that is unique for the ingress interface.
NOTE: If after turning on multicasting you notice high WLC CPU utilization, and also the wired network load has
increased, you should check if multicasting has been configured correctly, that IGMP snooping has been disabled on the
WLC as the AP’s will be handling this and also change the WLC from UNICAST-MULTICAST mode to MULTICASTMULTICAST mode and also assign an address in the 239.X.X.X/8 range.
NOTE: PIM routers listen to 224.0.1.39 in order to collect the RP information from all the candidate RP’s and send their
RP Discovery Messages on the 224.0.1.40 Group. Also, you should configure your network with pim dense mode.
Mapping Agents listen to 224.0.1.39 in order to collect the RP information from all candidate RPs and
send RP Discovery Messages on the 224.0.1.40 group
IGMP SNOOPING DISABLED BEHAVIOUR:

The controller always uses Layer 2 MGID when it sends multicast data to the AP. Every interface created is assigned
with one Layer 2 MGID. Management will have an MGID of 0 and the first dynamic interface will have an MGID of 8
and increment accordingly.

The IGMP packets from clients are forwarded to the router. As a result, the router IGMP table is updated with the
IP address of the clients as the last reporter.
IGMP SNOOPING ENABLED BEHAVIOUR:

The controller always uses Layer 3 MGID for all Layer 3 multicast traffic sent to AP’s. For all Layer 2 multicast traffic,
it continues to use Layer 2 MGID.

When a client is listening to a multicast group roams from one controller to another, the first controller transmits
all the multicast group information for that listening client to the second controller.
As a result, the second controller can immediately create the multicast group information for that client.
The second controller sends the IGMP reports to the network for all multicast groups to which the client was
listening. This process aids in the seamless transfer of multicast data to the wireless client.

If you have a multicast enabled network, choose “Multicast” from the AP Multicast Mode drop-down list to use the
method where the network replicates the packets.

If you do not have a multicast enabled network, choose Unicast from the AP Multicast Mode drop-down list to use
the method where the controller replicates the packets.

239.0.0.0-239.255.255.255 is the Multicast Group IP Address range. Do not use the 239.0.0.X address range or the
239.128.0.X address range. Addresses in these ranges overlap with the link local MAC addresses and will flood out
all switch ports even with IGMP snooping enabled.
NOTE: If you notice High CPU utilization after turning on multicast on a WLC with a large amount of AP’s its advised that
you use the unicast AP Multicast Mode feature to correct this issue.
CONFIGURING MULTICAST ON WLC:





In the GUI go to CONTROLLER > GENERAL to enable multicast. This is enabling multicast globally.
Select from one of the either two multicast modes: Multicast-Unicast Mode / Multicast-Multicast Mode.
If you are choosing Multicast-Multicast mode then you also need to entre in the Multicast Group IP Address.
Also enabled Broadcast forwarding as well.
Finally, under CONTROLLER >MULTICAST option, enable the “Global Multicast Mode” and “IGMP Snooping” option.
NOTE: Each WLC should have their own unique CAPWAP Multicast Group address, because if they are all the same it will
most likely cause a multicast storm.
mDNS MULTICASE DOMAIN NAME SYSTEM:
The Multicast Domain Name System (mDNS) service discovery provides a way to announce and discover the services on
the local network. The mDNS service discovery enables wireless clients to access Apple services such as “Apple Printer”
and “Apple TV” advertised within a local L2 network. mDNS performs DNS queries over IP multicast.
NOTE: Routers cannot use multicast routing to redirect the traffic because the time to live (TTL) is set to 1

Each query or advertisement is sent to the Bonjour multicast address for delivery to all clients within the subnet.
Apple’s Bonjour protocol relies on mDNS operating at UDP port “5353” and sent to the following reserved group
addresses: IPv4 Group Address - “224.0.0.251”

The addresses used by the Bonjour protocol are link-local multicast addresses, and thus are only forwarded to the
local vlan and thus leads to a stability issue.
To address this limitation, the WLC’s acts as a Bonjour Gateway. The WLC listens for Bonjour services both on the wired
and wireless and by caching those Bonjour advertisements (AirPlay, AirPrint, etc) from the source/host, it responds
back to Bonjour clients when a request for service is seen.
1.
2.
3.
4.
5.
The controller listens for the bonjour services being advertised.
If the WLC discovers a service, the controller cache those bonjour services.
The controller listens for the client queries for any services.
The controller sends a unicast response to the client queries for bonjour services that reside on other networks.
This way you can have the services and clients in different subnets.
NOTE: When debugging a mDNS gateway such as the WLC, you are looking for a Unicast reply from the WLC when
querying for a mDNS service in the Bonjour Cache.
NOTE: If after deploying a mDNS gateway you notice that devices are available all over the network, you must use the
mDNS-AP feature to restrict the mDNS advertisements to the AP and its adjacent AP’s.
LOCATION SPECIFIC SERVICES:
All the valid mDNS service advertisements (AirPlay, AirPrint, etc) that are received by the controller are tagged with the
MAC address of the AP that, that service advertisement was heard on while inserting a new entry into the service
provider database (SP-DB). This allows only the clients connected to the same AP as the service being advertised to have
access to it.
LSS filtering is only applied to the SP-DB entries. Wireless SP-DB entries are filtered based on the AP-NEIGHBOUR-LIST if
LSS is enabled for that particular service, thus only clients in the same “RF Neighbourhood” as the service being
advertised are grated permission to that service.
The response formulation to the client query, filters the wireless entries in the service provider database using the MAC
address of the AP associated with the querying client.
LSS applies only to wireless service provider database entries. There is no location awareness for a wired service
provider device. The status of LSS cannot be enabled for services with ORIGIN set to wired and vice versa. The purpose
of LSS is to limit the ability for a client to only access services at its local site and not at a different site for example.
By default, LSS is disabled on a WLC. TO enable LSS for a particular service use the following CLI command: There is no
option to enable this via the GUI.
(WLC) > show mdns service summary
(WLC) >config mdns service lss <enable / disable> <service_name/all>
PRIOIRTY MAC:
Priority MAC allows you to configure 50 MAC addresses per service and these mac addresses are the SP MAC’s which
needs priority. This guarantees that any service advertisements originating from these MACs for the configured services
will be learnt even if the SP-DB is full by deleting the last non-priority SP from the service having the highest number of
Service Provider.
While configuring the priority MAC address for a service, there is an optional parameter i.e. ap-group which only applies
to WIRED Service Providers to associate a sense of location to the wired SP devices. When a client mNDS query
originates from this ap-group the wired entries with priority MAC and ap-group will be looked up and those entries will
be listed first in the aggregated response.
NOTE: If you notice that not critical devices are filling up the SP-DB thus not allowing the critical devices to be discovered,
then it is recommended that you use the PRIORITY MAC feature to prevent this issue from happening.
To configure priority MAC run the following command from WLC CLI:
(WLC) >config mdns service priority-mac <add /delete> <service_name> [ap-group <group-name]
To verify use the show the priority MAC addresses configured for the service:
show mdns service detailed <service_name>
mDNS-AP:
The “mDNS AP” feature allows the controller to have visibility of wired bonjour services that are on VLANs which are
not visible to the WLC. You can configure any AP as an mDNS-AP and enable that AP to snoop and forward mDNS
packets to the WLC. The maximum number of VLAN’s that an mDNS-AP can snoop is 10.
The mDNS packets between the AP and the controller are forwarded in Control and Provisioning of Wireless APs
(CAPWAP) data tunnel that is similar to the mDNS packets from a wireless client. Only CAPWAP v4 tunnels are
supported.

If the AP is in an access port, you should not configure any VLANs on the AP to snoop as by default, the mDNS AP
snoops in the native VLAN.
NOTE: The mDNS-AP feature is supported only on local mode and monitor mode APs. The mDNS AP configuration is
retained on those mDNS APs even if global mDNS snooping is disabled.
To configure mDNS-AP on an AP in trunk mode use the following commands below:
(WLC) > show mdns ap summary
(Displays all the APs for which mDNS forwarding is enabled. 0 means not enabled)
(WLC)> config mdns ap enable/disable <APName/all> vlan <vlan-id>
(Enables AP snooping and configures which VLAN the AP should snoop and forward the mDNS packets.
(WLC) >config mdns ap vlan add/delete <vlanid> <AP Name>
To configure mDNS-AP on an AP in access mode use the following commands below:
(WLC) > show mdns ap summary
(Displays all the APs for which mDNS forwarding is enabled. 0 means not enabled)
(WLC)> config mdns ap enable/disable <APName/all> vlan <vlan-id>
RESTRICTIONS FOR CONFIGURING mDNS:

mDNS over IPv6 is not supported.

mDNS is not supported on APs in FlexConnect mode in a locally switched WLAN and Mesh AP’s.

The LSS, mDNS AP, Priority MAC address, and origin-based discovery features cannot be configured using the
controller GUI.
3: IMPLEMENT HIGH DENSITY: 13% WEIGHTING ON THE EXAM
RECEIVE START OF PACKET (RXSOP):
Receiver Start of Packet Detection Threshold (RX-SOP) determines the threshold level in dBm at which an AP radio will
demodulate and decode a received packet. The higher the RX-SOP level, the less sensitive the radio is and the smaller
the receiver cell size will be.
Reducing cell size, we ensure that the clients are connected to the nearest AP using the highest possible data rates. This
is ideal for high density environments such as stadiums and large auditoriums where there are a large number of client
devices connected per AP.
802.11 Band
5 GHz
2.4 GHz
High Threshold
-76 dBm
-79 dBm
Medium Threshold
-78 dBm
-82 dBm
Low Threshold
-80 dBm
-85 dBm
Auto
Use Radio Default
Use Radio Default
The RX-SOP default threshold value is Auto, which means that the RX-SOP threshold is set to the radio’s default value.
This value is determined by the chipset manufacture.
All frames received with weaker RSSI than configured RX-SOP will be classified as non-Wi-Fi frames and will not get
decoded by the radio. Packets that are not decoded are treated as non-Wi-Fi interference and detected at the AP as
noise.

RX-SOP is supported on the following AP Models: 1552, 1570 ,1600 ,1700, 2600, 2700, 3500, 3600, 3700

RX-SOP can be configured either via the GUI or CLI. The command for CLI is as follows: config 802.11<a/b> rx-sop
threshold <level> (Auto, Low, Medium, High)
NOTE: Only an RF-Profile can override the global RX-SOP settings when they are applied.
OPTIMIZED ROAMING:
Sticky clients are when they do not roam to a nearby AP connection that has stronger signal strength. A lower signal
strength will lead to increase in Airtime interference, thus reducing the overall performance.
Cisco Optimized Roaming addresses the sticky client challenge by pro-actively disconnecting clients, thus forcing the
client to move to a nearby AP that offers stronger connectivity. It achieves this functionality by actively monitoring Data
RSSI packets and enforcing client disassociation when the RSSI is lower than the set threshold.
As an example, clients with signal strength lower than -80 RSSI will be disassociated. This achieves the following:


Client receives best connectivity and maintains the quality of experience.
Improves overall performance of each AP cell by reducing Airtime interference.
Optimized Roaming default settings are data RSSI value that is set to -80 dBm, the coverage exception level is 25%, and
the default number of packets is 50.
So, by default, when Optimized Roaming is enabled and more than 25% of at least 50 packets in a 5 second period is less
than -80 Data RSSI, the AP will disassociate the client once the reporting interval of 90 seconds expires.
The goal of the Optimized Disabled Roaming feature is only to affect clients that are connected on legacy data rates.
These are the clients that are using a majority of the Airtime. This value applies the Optimized Roaming feature to
clients connected at this data rate or lower. By default, this is disabled.
NOTE: The client will be allowed to re-join the AP when the client RSSI value has increased to 6 dBm above the
disassociation threshold. For example, if the Data RSSI threshold is -80 dBm, the client will be allowed to re-associate
once the RSSI values is increased to -74 dBm, so therefore the hysteresis is 6 dBm.
4: DESIGN AND DEPLOY WIRELESS INFRASTRCUTURE FOR MOBILTY: 18% WEIGHTING ON THE EXAM
INTERFACE GROUPS:
Interface groups are logical groups of interfaces like a port-channel on a switch. Interface groups facilitate user
configuration where the same interface group can be configured on multiple WLANs or while overriding a WLAN
interface per AP group. However, unlike a switch an interface can be part of multiple interface groups. A WLAN can be
associated with either an interface or interface group.
A main benefit of having interface groups with multiple interfaces assigned to it is that you can configure AAA override
for interface groups. This feature extends the current AP Group and AAA override architecture where AP Groups and
AAA override can be configured to override the interface group WLAN that the interface is mapped to. This is possible
when multiple interfaces are assigned to an interface group.
Interface groups allow you to configure guest anchor restrictions where a wireless guest user at a foreign location can
obtain an IP address from multiple subnets on the foreign location and controllers from within the same anchor
controller.
NOTE: The interface group name and the interface name cannot be the same.
AP GROUPS:
AP Groups are created to assigned a specific set of AP’s unique configuration settings other than what has been set
globally on a WLC.
By default, each AP is automatically assigned to a default AP group named “default-group” and WLANs IDs (1-16) map
to this default group. WLANs with IDs greater than 16 require a custom AP group to be defined. When customized AP
groups are defined on a WLC, the APs must be manually assigned to the AP group.
Supported AP group specific configurations include:

CAPWAP Preferred Mode – Used to determine if the AP prefers IPv4 or IPv6 CAPWAP modes.

WLAN – WLAN assignments, interface / interface group mappings and NAC state.

RF Profile Assignments – 802.11, RRM, high density and client load balancing configurations.
If both the WLAN interface/interface group and AP Group interface mappings are the same, then changes to the WLAN
interface mapping changes will automatically change the interface mapping in the AP Group. If they are both different
to begin with then the AP Group interface overrides things and changes to the WLAN interface/interface group are not
automatically applied.
The OfficeExtend 600 Series AP supports a maximum of two WLANs and one remote LAN. If you have configured more
than two WLANs and a remote LAN on the WLC, you must assign the Office Extend 600 Series APs to a custom AP group.
The support for two WLANs and one remote LAN still applies to the default AP group. Additionally, the WLAN/remote
LAN ID’s must be lower than 8.
MOBILITY CONTROL PLANE ARCHIECTURE:
Mobility Groups are created so WLC’s can dynamically share essential client, AP and RF data among them as well as
forward client data traffic when inter-controller / inter-subnet roaming events occur.
Mobility Groups are used to help facilitate seamless client roaming between APs that are joined to different WLCs. All
peers within a mobility group create a peer link with each other member, thus creating a full mesh peering topology.
Internet Protocol
Version 4
IP Protocol
17 (UDP)
97 (IP)
SRC / DST Port
16666
-
Description
IPv4 Mobility Tunnel Control Channel every 30 seconds
IPv4 Mobility Tunnel Data Channel
NOTE: Mobility packet uses UDP port 16666. Because UDP is an unreliable delivery mechanism, any packets that requires
a response retries up to 4 times at one-second intervals.
Mobility Group Constraints:

Up to 24 x WLCs (any model) can be assigned to a single Mobility Group. A maximum of 144,000 AP’s are supported
within a single Mobility Group.

The WLCs do not have to be of the same model or type to be a member of a mobility group, however it is
recommended that each member should be running the same software version but this is not mandatory.

WLCs in SSO mode within a mobility domain see each as peers.

A mobility group requires all WLCs in the group to use the same virtual IP address.

Each WLC must use the same Mobility Domain name and be defined as a peer in each other’s Static Mobility
Members list. Exception to this rule is when guest anchors are deployed, which should be in a separate Mobility
Group.

For wireless clients to seamlessly roam between Mobility Group members (WLCs), the WLAN and security
configuration must be consistent across all WLCs in the same the mobility group.

As part of Mobility Groups, Cisco recommends turning on Multicast Mobility features on all peers within the group.
NOTE: A WLC that is configured as an Auto Anchor does not have to be in the same mobility group as the foreign WLCs.
It is possible for a WLC to be a member of one Mobility Group i.e MG-A while at the same time, act as an auto anchor for
a WLAN originating from foreign WLCs i.e Mobility Group MG-B that are members of other mobility groups as long as
each WLC is added to each othere mobility lists.
Any device on an IP network has an IP point of Presence (PoP). Usually it is made of client IP address & MAC address. If
the client moves to another AP associated to a different WLC, the point of association or attachment (PoA) now changes
to that foreign controller whereas PoP remains at the initial WLC (Now known as an Anchor after a roam to a Foreign
WLC).
NOTE: Point of Presence (PoP) means that where the client is seen on the network. So if a client roams to an AP on
another WLC, its PoA is on that foreign WLC, however its PoP on the wired network is still being seen from the initial WLC
is connected too.
In roaming situations, the role of WLC can change to any of the below:
Local: This controller is providing both PoP & PoA.
Anchor: This controller is providing PoP only & always paired with a foreign controller which will be provide PoA.
Foreign: This controller is providing PoA only & always paired with an Anchor controller which will provide PoP.
Export Anchor: This controller is providing PoP only and always paired with an Export Foreign controller.
Export Foreign: This controller is providing PoA only and always paired with an Export Anchor controller.
MOBILITY TUNNELLING PROCESS:
Intra-Controller-Roaming: If a client roams between APs on the same WLC, it is known as an intra-controller mobility
event / roam. This is the most simplistic roaming event where WLC simply update the database with client state &
security context as client roam from AP1 to AP2.
Inter-Controller Roaming L2: Inter-Controller (Normally Layer 2) roaming occurs when a client roam between two APs
registered to two different WLC’s respectfully, where each WLC has access to the client’s subnet. i.e VLAN 20.
In this instance WLC’s exchange mobility control messages (over UDP port 16666) and the client database entry
is moved from the original WLC to the new WLC via these messages.
(WLC1) >show client detail 00:1b:d4:58:e6:1a
AP Name.......................................... LWAP-02
IP Address....................................... 10.10.14.54
Mobility State................................... Local
(WLC2) >show client detail 00:1b:d4:58:e6:1a
AP Name.......................................... LWAP-03
IP Address....................................... 10.10.14.54
Mobility State................................... Local
Inter-Controller Roaming L3: If a client roams between APs registered to different WLC’s and the client’s WLAN on each
of the WLC’s is mapped to a different subnet, then this is known as an inter-controller L3 roam. i.e WLC-A WLAN 1 =
VLAN 20 and WLC-B WLAN 1 = VLAN 30.
With an Inter-Controller L3 roam, the two WLC’s exchange mobility messages as per normal. However, the client
database entry change is completely different that to of a L2 Roam.
NOTE: Instead of moving the client database entry during a L2 Roam it will copy it during a L3 roam to the foreign WLC).
WLC-A will mark the client entry as “Anchor” whereas WLC-B will mark its client entry as “Foreign “and the two WLC’s
are now referred to as an “Anchor Controller” & “Foreign Controller” respectively.
This type of roam allows the client to keep their original IP address which is the real advantage of this type of mobility
peering. This is especially critical for wireless IP phones as the time it takes for a new DHCP request will impact the voice
call.
EXAMPLE BEFORE ROAM:
(WLC1) >show client detail 00:1b:d4:58:e6:1a
Client MAC Address...............................
AP Name..........................................
Wireless LAN Id..................................
IP Address.......................................
Mobility State...................................
Interface........................................
00:1b:d4:58:e6:1a
LWAP-02
4
10.10.14.54
Local
vlan14
EXAMPLE AFTER ROAM:
(WLC1) >show client detail 00:1b:d4:58:e6:1a
AP MAC Address...................................
AP Name..........................................
IP Address.......................................
Mobility State...................................
Mobility Foreign IP Address......................
Interface........................................
00:00:00:00:00:00
N/A
10.10.14.54
Anchor
10.10.112.10
vlan14
(WLC2) >show client detail 00:1b:d4:58:e6:1a
AP MAC Address...................................
AP Name..........................................
IP Address.......................................
Mobility State...................................
Mobility Anchor IP Address.......................
Interface........................................
64:a0:e7:af:47:40
LWAP-03
10.10.14.54
Foreign
10.10.111.10
vlan12
NOTE: It is important to remember that a Layer 3 mobility event only occurs when the assigned subnet to the WLAN
between the WLC’s is not the same. Whether or not the management interfaces of each WLC are in the same subnet has
no bearing on a client Layer 3 roaming event.
ROAMING BACK TO THE ORIGNAL WLC: When the client roams back to its orignal / initial WLC the Anchor and Foreign
markings are removed and the client database entry is deleted from the Foreign WLC. If the client should roam to a
second Foreign WLC such as WLC-C, the original Anchor WLC is maintained, and the Foreign client entry is either copied
or move to the new Foreign WLC depending on the roam type.
NOTE: It is possible for a client to perform a L2 roam, then roam back to its original WLC and then perform a L3 roam etc.
This is not ideal but is possible. Cisco recommends to keep inter-controller roaming to a minimum, thus careful planning
of your wireless network is required.
Static Client IP: If your client is configured with a static IP address, when that client roams to another WLC that does not
have access to the same subnet as the static IP, the client will fail to connect to the network. You must enable dynamic
anchoring / tunnelling so that clients with static IP addresses can continue to work on the network.
The following sequence of steps occur when a client with a static IP address tries to roam to a foreign controller:
1: The foreign WLC will perform a mobility announcement. If a controller in the Mobility Group responds, the client’s
traffic is tunnelled to that controller which now also becomes the (Anchor).
2: If none of the WLC’s respond, the client is treated as a local client and authentication is performed again. If the
client’s IP subnet is not supported on the WLC, the WLC will send another static IP mobile announce and if another WLC
which has access to the client’s subnet responds to that announce, the client traffic is tunnelled via EoIP to that WLC
that responded.
3: As a result, the WLC which the clients traffic is being tunnelled from becomes the Export Foreign WLC and the WLC
where the connection was initialized becomes the Export Anchor WLC.
With this configuration, both the send and return traffic are tunnelled via the Export Anchor WLC which is known as
Symmetrical Tunneling. This is because the Export Anchor WLC is the WLC that has access to the same subnet that the
Static Client’s IP address is part off.
In order to enable dynamic tunnelling, you must enable “Static IP Tunnelling” which is configured on the WLAN itself.
This should be enabled on every WLAN where you wish to support wireless clients with Static IP Addresses. Finally, you
also need to disable “DHCP REQUIRED” on the WLAN if it is turned on.
To configure this via CLI commands: config wlan static-ip-tunneling {enable | disable} <wlan_id>
(WLC3) >show wlan 5
WLAN Identifier.................................. 5
Static IP client tunneling....................... Enabled
AUTO-ANCHORING MOBILITY:
Typically, within mobility groups, whatever the first WLC that the client connects to is considered the local WLC. This can
be ever changing as it depends solely on which WLC the client initially connected with. However, there are sometimes
situations that you may want to statically tunnel your clients traffic to a different WLC. This is also known as an Anchor.
Auto-Anchor Mobility: Auto Anchoring is when you statically set which WLC will be an Anchor for a WLAN within the
mobility domain. Most common use of Auto-Anchor is when a Wireless Guest WLAN service is offered at remote sites
where you require all the guest traffic to be tunnelled back to DMZ controller for security purposes.
Auto-Anchoring is achieved the same way as typical Anchoring by using an EoIP tunnel from a Foreign WLC back to the
Anchoring WLC, in most cases this Anchor WLC is located in the DMZ. Irrespective of where they associate to network
their traffic will be tunnelled back to this Anchor WLC.
The steps involved to configure Auto-Anchor are outlined below (via GUI):
1: Create the “Guest” WLAN: The ‘Guest’ WLAN needs to be created on all the remote WLC’s that wish to offer this
Guest WLAN service to clients.
NOTE: These WLAN’s need to have their interface mapped to the management interface and NOT a dynamic interface.
2: Enable Web-Authentication: The “Guest” WLAN will need to have WebAuth enabled thus allowing guest users to
entre in a username and password credentials to gain access.
3: Verify Mobility Group Settings: Prior to statically setting the DMZ WLC as the Anchor on the remote branch WLAN’s,
it must be added to the Mobility List / Domain. This needs to be verified as if it is not listed, then it cannot be set within
the WLAN.
4: Set Anchor for WLAN: Next step is to configure is to actually set the which WLC will be the Anchor for the ‘Guest’
WLAN on the remote branch WLC’s. As seen below the little arrow on the right-hand arrow pops down and select
Mobility Anchors. Here is where you select the IP Address of the WLC in the DMZ. For the WLC in the DMZ, this process
is the same, however you select “LOCAL” instead.
NOTE: Only the Auto-Anchor WLC in the DMZ will have the Guest WLAN mapped to a dynamic interface. The remainder
of the WLC will have their WLAN’s mapped to their management interfaces.
MINIMIZE INTER-CONTROLLER ROAMING:
Cisco recommends to try and minimise the distribution of AP’s spread across WLC’s in the Mobility Group, for example
per floor or per controller, and not a salt and pepper distribution. This reduces inter-controller roaming, which has less
impact on the mobility group activity. Intra-controller roaming is always better than inter-controller roaming.
NOTE: The salt & pepper affect is when a particular floor or wireless deployment has random AP’s on one WLC and the
remainder on another WLC within the same Mobility Group.Whilsts clients should roam seamlessly, its best practice to
keep not distribute them across WLC’s.
Additionally, when configuring APs, always set the primary/secondary WLC names, to control the AP selection during
the CAPWAP join process. This can prevent "salt & pepper" scenarios that affect roaming time, make troubleshooting
simpler and have a more predictive network operation.
MOBILITY MESSAGE TYPES:
There are 11 different mobility messages which are as follows:
•
Controller Announce: Sent every 20 seconds as long as the WLC is operational and carries no status information.
• Mobile Announce: Sent when a client first associates with a WLC. The WLC sends up to four “mobile announce”
messages. The message can be sent as either a unicast to each WLC within the Mobility Group or a multicast to the
Mobility Group’s multicast IP address.
As long as no Mobile Handoff message is received, the WLC will create a Local client session. If the client was
previously associated with another WLC in the Mobility Group, that WLC will send a Mobile Handoff to the new
controller. Only WLC’s with a Local or Foreign client session can send a Mobile Handoff.
A WLC with an Anchor client session never answers the Mobile Announce message. The Mobile Announce contains
sufficient information to allow a local or foreign WLC receiving the packet to determine the type of connection to
which the client will transition on the new WLC and the type of mobility transfer that will be necessary.
•
Mobile Handoff: Sent when a mobile client session is either transferred or a new foreign client session is
established. It is always sent in response to a Mobile Announce and is always a unicast message.
•
Mobile Anchor Request: Sent by the new foreign controller to the anchor controller when it receives a handoff
from another foreign controller. It notifies the anchor that the new foreign controller is ready to take over from the
old foreign controller.
•
Mobile Anchor Grant: Sent by the anchor controller to the new foreign controller in response to a Mobile Anchor
Request. It is only sent in response to an Anchor Request.
•
Mobile Anchor Transfer Request: Sent by the old foreign controller to the anchor controller when it sends a
handoff to the new foreign or local controller. It notifies the anchor that the new controller is ready to take over.
•
Mobile Anchor Transfer ACK: Sent by the anchor controller to the old foreign controller in response to a Mobile
Anchor Transfer Request. It is only sent in response to an Anchor Transfer Request. It closes the client session on
the old foreign controller.
•
Mobile Handoff End: Sent by either the anchor or foreign controller to its respective peer to inform the peer that
the client session is being terminated.
•
Mobile Handoff End ACK: Sent in response to a Mobile Handoff End.
•
Anchor Export Request: Sent when a mobile client first associates with a controller, the controller has not received
a handoff in response to the mobile announcement, and the WLAN is configured for Auto-Anchor. It is sent as a
unicast message to a single controller configured as an Export Anchor for that WLAN.
•
Anchor Export ACK: Sent in response to an Anchor Export Request. It is always a unicast message sent to the
controller that sent the Anchor Export Request.
HANDOFF TYPES:
Handoffs occur only between WLC’s in the same mobility group. A Mobile Handoff is sent when a mobile client session
is either transferred or a new foreign client session is established. It is always sent in response to a Mobile Announce.
The mobile client connection to the network can take two forms:
•
A Local Connection: Where the client IP point of presence on the wired LAN (the subnet containing the client IP
address) and the AP to which the client is associated are both directly accessible through a single controller.
•
An Export Anchor-Export Foreign (symmetric mobility) Connection: Where the client IP point of presence is
accessible through one controller (the Anchor) and the AP to which the client is associated is accessible through
another controller.
There are 6 types of mobility handoffs:
Local-To-Local: These handoffs occur when the client performs a Layer 2 roam between two WLC’s and requires only
two packets. Below is an example of a Local-to-Local Handoff.
When the client roams to an AP on WLC1, WLC1 sends a Mobile Announce to the mobility group members. WLC1
responds with a Mobile Handoff, and the client database entry is moved from WLC1 to WLC2. WLC1 no longer has the
client database entry. WLC2 becomes the IP point of presence for the client.
Local-To-Foreign: Local-to-Foreign Handoff occurs when the client performs a Layer 3 (inter-controller inter-subnet)
roam and requires only two packets. Below is an example of a Local-to-Foreign Handoff.
As seen, in a Local-to-Foreign Handoff, when the client roams from WLC1 to WLC2, WLC2 sends a Mobile Announce, and
WLC1 responds with a Mobile Handoff. The client database entry is copied from WLC1 to WLC2. WLC1 marks the client
entry as Export Anchor, and WLC2 marks the client entry as Export Foreign. The IP point of presence for the client
remains WLC1.
Foreign to Local Type 1: A Foreign-to-Local type 1 Handoff is the opposite of the Local-to-Foreign Handoff and again
requires only two packets. The client is roaming from the foreign controller back to the original anchor controller it
came from. Below is an example a Foreign-to-Local (1) Handoff.
As seen, when the client roams back to WLC1, WLC1 sends out a Mobile Announce, and WLC2 responds with a Mobile
Handoff. WLC1 knows it used to have a Local entry for that client and removes the Export Anchor designation from the
client entry and once again marks it as Local. WLC2 deletes the database entry for the client. WLC1 remains the IP point
of presence for the client.
Foreign to Local Type 2: With a Foreign-to-Local type 2 Handoff, three controllers are involved and four packets are
needed. The client roams from the foreign controller to a third controller whose WLAN is in the same subnet as the
anchor controller.
As shown, when the client roams to WLC3, WLC3 sends out a Mobile Announce, and WLC2 responds with a Mobile
Handoff. The client database information is extracted from WLC2 by WLC3. WLC2 sends a Mobility Handoff End, and
WLC1 responds with a Mobility Handoff End ACK. WLC1 and WLC2 delete the client database entry, and WLC3 marks
the client entry as Local because its WLAN is in the same subnet as the client IP and becomes the IP point of presence
for the client.
Foreign-to-Foreign Handoffs: These types of handoffs involve three controllers and require six packets to complete the
transaction. The client data path is set up after the first three packets are processed. This is the most complicated
handoff transaction. A Foreign-to-Foreign Handoff occurs whenever the client has already established an Export Anchor-
Export Foreign connection and the new controller to which the client has associated does not share a common subnet
assignment with the anchor controller for the WLAN in which the client is roaming as seen below.
As shown, when the client roams to WLC3, WLC3 sends out a Mobile Announce to the mobility members. WLC2
responds with a Mobile Handoff, and all client entry information is extracted from WLC2 and transferred to WLC3.
After sending the Mobile Handoff, WLC2 sends an Anchor Xfer message to the WLC1, at which time WLC1 responds with
an Anchor Xfer ACK and sets up the new client forwarding path. WLC2 then deletes the client session. WLC3 sends an
Anchor Req message to WLC1, and WLC1 responds with an Anchor Grant message. The IP point of presence for the
client remains with WLC1.
Auto-Anchor Transfer: If a WLAN is configured for auto-anchoring, the setup of the client upon entering the network is
different from normal. When the client associates, the controller sends out Mobile Announce messages as seen below
to the mobility members like normal just in case the client is roaming from another controller. A mobility auto-anchor
controller never responds to a Mobile Announce message.
After WLC2 sends the fourth Mobile Announce and does not receive a Mobile Handoff from any other controllers in the
mobility group, instead of creating a Local entry for the client, WLC2 sends an Export Anchor Request to WLC1, which is
configured as the auto-anchor for the client WLAN. The anchor controller responds with an Export Anchor ACK.
The client database entry is copied to the anchor controller. WLC1 marks the client entry with Export Foreign, and WLC1
marks the entry as Export Anchor. WLC1 is the IP point of presence for the client. With the auto-anchoring scenario, you
have a fixed anchor controller for the client WLAN that will never change. The client will have an IP address in the same
VLAN as the anchored WLAN interface on WLC1.
MOBILITY AGENT:
A mobility agent manages AP connectivity and builds a database of client stations (endpoints) that are served locally as
well as roamed from an Anchor WLC. Mobility agent can be either a Catalyst 3850 or a CT5760 mobility controller with
an internal mobility agent running on it.
SWITCH PEER GROUP (SPG):
Converged Access deployments defines an SPG as a logical group of mobility agents within one mobility controller (or
mobility sub-domain). The main advantage of configuring SPGs is to constrain the roaming traffic to switches that form
this SPG.
When the mobility agents are configured in one SPG on the mobility controller, the software automatically forms full
mesh CAPWAP tunnels between the mobility agent switches. These CAPWAP tunnels can be formed in a multi-layer
network design (where the mobility agent switches are L2 adjacent on a VLAN spanned across) or a routed access design
(where the mobility agent switches are L3 adjacent).
The SPGs should be designed as a group of mobility agent switches to where the users frequently roam.
CREATING MOBILITY GROUPS:
In order to create a mobility group, each WLC needs to be statically defined on each other WLC. This to create a full peer
mesh. Unicast Mobility messaging is not efficient if you have multiple WLC’s in the same Mobility Group. You should
allocate a multicast group address for inter-controller mobility messages.
The steps involved are outlined below (via GUI):
1: Enable Mobility Multicast Messaging: As stated above it is more efficient to enable Mobility Multicast Messaging if
you have multiple WLC’s within the same mobility group.
2: Add Mobility Group Members: On WLC1 you will need to add all of the other WLC’s IP ADDRESS and their MAC
ADDRESS. Below is an example of adding in a single WLC’s details.
3: Verify Peering: Once this process has been completed on each of the WLC’s that have been added in the mobility
group / domain should change their status from “Control and Data Path Down” to UP as per the example below.
NOTE: During the exam, MAKE SURE YOU SAVE YOUR CONFIG.
You can use show mobility summary to verify from the CLI if the peering is up between the local WLC and other WLC’s
as per the example below.
(WLC2) >show mobility summary
Symmetric Mobility Tunneling (current) ..........
Symmetric Mobility Tunneling (after reboot) .....
Mobility Protocol Port...........................
Default Mobility Domain..........................
Multicast Mode ..................................
Mobility Domain ID for 802.11r...................
Enabled
Enabled
16666
mrn-cciew
Enabled
0x4ccd
Controllers configured in the Mobility Group
MAC Address
IP Address
Group Name
00:0b:85:40:a1:c0 10.10.112.10
mrn-cciew
00:0b:85:43:d8:60 10.10.111.10
mrn-cciew
Multicast IP
239.239.239.239
239.239.239.239
The steps involved are outlined below (via CLI):


config mobility group domain ccnp-wireless
config mobility group member add 00:0b:85:40:a1:c0 10.10.112.10 ccnp-wireless


config mobility multicast-mode enable 239.239.239.239
config mobility group multicast-address ccnp-wireless 239.239.239.239
Status
Up
Up
MOBILITY LISTS / DOMAIN:
A mobility domain or list is a collection of WLC’s that have all been configured with each other’s MAC and IP addresses,
which allows clients to roam between the WLC’s in the mobility domain.
A WLC can support up to 72 WLC’s in the mobility list which allows seamless roaming across multiple mobility groups.
Cisco Mobility has two categories, Mobility Domains & Mobility Groups. If WLCs are configured with the same mobility
domain they will communicate with each other, however if WLC’s are in the same Mobility Group, this allows the
distribution of security context of a client among those WLC’s. It also constrains AP fail-over between WLC’s.
A WLC supports 3 mobility groups with up to 24 controllers in a single group for a total of 72 controllers in the mobility
domain (or list).
VIRTUAL INTERFACES (WLC):
The virtual interface is used to support mobility management, Dynamic Host Configuration Protocol (DHCP) relay, and
embedded Layer 3 security.
Specifically, the virtual interface plays these two critical roles:


Acts as the DHCP server placeholder for wireless clients that obtain their IP address from a DHCP server.
Serves as the redirect address for the web authentication login page.
The virtual interface IP address is used only in communications between the controller and wireless clients. It never
appears as the source or destination address of a packet that goes out a distribution system port and onto the switched
network.
For a WLC to operate correctly, the virtual interface IP address must be set (it cannot be 0.0.0.0), and no other device
on the network can have the same address as the virtual interface. Therefore, the virtual interface must be configured
with an unassigned and unused gateway IP address.
The virtual interface IP address is not pingable and should not exist in any routing table in your network. In addition,
the virtual interface cannot be mapped to a physical port.
NOTE: All WLC within a mobility group must be configured with the same virtual interface IP address. Otherwise, intercontroller roaming may appear to work, but the handoff will not complete, and the client loses connectivity for a period
of time.
MOBILITY OPTIMIZATION (11k/11v):
802.11K: 802.11k allows clients to request a neighbouring AP report from the AP that it is currently connected too. This
report contains information about known neighbouring APs that the reporting AP can hear thus influencing & improving
the clients roaming decision.
Process Involved:

The client once connected will send a request to its currently connected AP requesting for a list of APs that it could
potentially roam too.

The AP will send a reply back to the requesting client, a list of nearby APs and their channels that it can hear for the
same WLAN.

If the client decides an AP to roam from the neighbour list, the client will not probe all of the 2.4 GHz and 5 GHz
channels.
Benefits of using 802.11K:

This will reduce roam times and improves the decisions taken by a client.

Increases battery life of the device as it neither changes the radio configuration for each channel nor sends probe
requests on each channel.

It avoids the device to process all the probe response frames. Thus, increasing bandwidth.
The use of the 802.11k neighbour list can limit the need for active and passive scanning of a client. The 802.11k
neighbour list is generated dynamically on-demand and is not maintained on the controller.
By default, the neighbour list contains only neighbours in the same band with which the client is associated. However,
the dual-list configuration allows 802.11k to return neighbours in both bands.
NOTE: Clients can send requests for 802.11k neighbour lists only after they associate with the APs that advertise the
Radio Management (RM) capability Information Element (IE) in its beacons.
When the WLC receives a request for an 802.11k neighbour list from the AP, the following occurs:
1. The WLC searches the resource management (RM) neighbour table for a list of neighbours on the same band as the
AP with which the client is currently associated too.
2. The WLC checks the neighbours according to the Received Signal Strength Indication (RSSI) between the APs, the
current location of the present AP, the floor information of the neighbouring AP from Cisco Prime Infrastructure, and
roaming history information on the controller to reduce the list of neighbours in the list to six per band.
802.11V: BSS Transition is applied to the following three scenarios:

Solicited Request – A client can send an 802.11v BSS Transition Management Query before roaming to gauge its
options of which AP to re-associate with.

Unsolicited Load Balancing Request - If an AP is heavily loaded, it sends out an 802.11v BSS Transition
Management Request to an associated client trying to influence it to connect to a different AP instead.

Unsolicited Optimized Roaming Request - If a client's RSSI and rate do not meet the requirements, the AP sends
out an 802.11v BSS Transition Management Request to the client.
802.11v BSS Transition Management Request is a suggestion given to client. The client will still need to make its own
decision whether to follow the suggestion or not.
To force disassociating a client, you can turn on the disassociation-imminent function. This function is to disassociate
the client after a period of time if the client does not re-associate to another AP.
NOTE: 802.11V with OPTIMZED ROAMING will work differently than just using either one of these features on their own.
5: IMPLEMENT CISCO MSE ARCHITECTURE: 12% WEIGHTING ON THE EXAM
CONTEXT AWARE:
Context Aware is the ability to track the physical location of Network Devices, both wired and wireless, using wireless
WLCs and Cisco AP’s. This solution allows a customer to track any Wi-Fi device, including clients, active RFID tags, and
rogue clients i.e Rogue AP’s.
ADAPTIVE WIPS:
wIPS software provides visibility and comprehensive threat prevention for the mobility network through monitoring,
alerts, classifying, and remediation of wireless and wired network vulnerabilities.
CLEANAIR
CleanAir provides the visibility all of the users of the shared spectrum (both native devices and foreign interferers). It
also enables you or your network to act upon this information.
For example, you could manually remove the interfering device, or the system could automatically change the channel
away from the interference. CleanAir provides spectrum management and RF visibility.
A Cisco CleanAir system consists of CleanAir-enabled APs, WLC’s, and Prime Infrastructure. CleanAir AP’s collect
information about all devices that operate in the industrial, scientific, and medical (ISM) bands, identify and evaluate
the information as a potential interference source, and forward it to their respective WLC.
The WLC controls the APs, collects spectrum data, and forwards information to Cisco Prime Infrastructure or a Cisco
mobility services engine (MSE) upon request to compute.
For every device operating in the unlicensed band, Cisco CleanAir tells you what it is, where it is, how it is impacting your
wireless network, and what actions you or your network should take.
Wireless LAN systems operate in unlicensed 2.4 & 5-GHz ISM bands. Many devices, such as microwave ovens, cordless
phones, and Bluetooth devices also operate in these bands and can negatively affect Wi-Fi operations.
Some of the most advanced WLAN services, such as voice over wireless and IEEE 802.11n radio communications, could
be significantly impaired by the interference caused by other legal users of the ISM bands. The integration of Cisco
CleanAir functionality into the Cisco Unified Wireless Network addresses this problem of radio frequency (RF)
interference.
LOCATION TECHNIQUES:
Location tracking and positioning approaches differ in terms of the specific techniques used to sense and measure the
position of a mobile device in the target environment under observation.
Typically, Real Time Location Systems (RTLS) can be grouped into four basic categories of systems that determine
position on the basis of the following:




Cell of Origin (Nearest Cell)
Distance (Lateration)
Angle (Angulation)
Location Patterning (Pattern Recognition)
CELL OF ORIGIN: One of the simplest mechanisms of estimating approximate location in any system based on RF "cells"
is the concept of cell-of-origin (or "associated AP" in Wi-Fi 802.11 systems).
This technique resolves the position of the mobile device by indicating which cell with which the mobile device is (or has
been) connected too. When applied to 802.11 systems, this technique tracks the cell to which mobile device it
associates with.
Cell of origin does not require the implementation of complicated algorithms and thus positioning performance is very
fast. Almost all cell-based WLANs and other cellular-based RF systems can be easily and cost-effectively adapted to
provide cell of origin positioning capability.
However, a large limitation of Cell Origin tracking is the lack of accuracy in tracking. For various reasons, mobile devices
can be associated to cells that are not in close physical proximity, despite the fact that other nearby cells would be
better candidates. This limitation to resolve the actual accurate location of a mobile device in a multi-story structure
where there is considerable floor-to-floor cell overlap can cause issues.
To better determine which areas of the cell, possess the highest probability of containing the mobile device, a
computer-assisted method such as received signal strength indication (RSSI) for mobile devices, the use of the highest
signal strength technique can improve location accuracy within the cell of origin.
In this approach, the localization of the mobile device is performed based on the cell that detects the mobile device with
the highest signal strength.
TIME DIFFERENCE OF ARRIVAL (TDoA): These techniques use relative time measurements at each receiving sensor in
place of absolute time measurements. Because of this, TDoA does not require the time of a mobile device to be
synchronized in order to resolve timestamps and determine location. With TDoA, a transmission with an unknown
starting time is received at various receiving sensors, with only the receivers requiring time synchronization.
TDoA implementations are calculated upon a mathematical concept known as hyperbolic lateration. In this approach, at
least three time-synchronized receiving sensors are required.
As shown above, assume that when station X transmits a message, this message arrives at receiving sensor A with time
TA and at receiving station B with time TB. The time difference of arrival for this message is calculated between the
locations of sensors B and A as the positive constant k, such that:
TDoAB-A = | TB - TA | = k
ToA and TDoA have several similarities. Both have proven to be highly suitable for large-scale outdoor positioning
systems. In addition, good results have been obtained from ToA and TDoA systems in semi-outdoor environments such
as amphitheatres and stadiums, as well as contained outdoor environments such as car rental and new car lots or ports
of entry.
Indoors, TDoA systems exhibit their best performance in buildings that are large and relatively open, with low levels of
overall obstruction and high ceilings that afford large areas of clearance between building contents and the interior
ceiling. It is precisely in these open, spacious environments that TDoA and ToA-based systems operate at their peak
efficiency and performance.
TIME OF ARRIVAL: These systems are based on the precise measurement of the arrival time of a signal transmitted from
a mobile device to several receiving sensors.
Because signals travel with a known velocity the distance between the mobile device and each receiving sensor can be
determined from the elapsed propagation time of the signal traveling between them.
The ToA technique requires very precise knowledge of the transmission start time(s) and must ensure that all receiving
sensors as well as the mobile device are accurately synchronized with a precise time source. From knowledge of both
propagation speed and measured time, it is possible to calculate the distance (D) between the mobile device and the
receiving station:
D = c (t)



D= distance (meters)
c = propagation speed of ~ 300 meters / microsecond
t = time in microseconds
With distance used as a radius, a circular representation of the area around the receiving sensor can be constructed for
which the location of the mobile device is highly probable. ToA information from two sensors resolves a mobile device
position to two equally probable points. ToA tri-lateration makes use of three sensors to allow the mobile device
location to be resolved with higher accuracy.
Above illustrates the concept of ToA tri-lateration. The amount of time required for a message transmitted from station
X to arrive at receiving sensors A, B, and C is precisely measured as tA, tB, and tC. Given a known propagation velocity
(stated as c), the mobile device distance from each of these three receiving sensors can then be calculated as DA, DB,
and DC, respectively.
Each calculated distance value is used to construct a circular plot around the respective receiving sensor. From the
individual perspective of each receiver, station X is believed to reside somewhere along this plot. The intersection of the
three circular plots resolves the location of station X as illustrated above.
In some cases, there may be more than one possible solution for the location of mobile device station X, even when
using three remote sensors to perform tri-lateration. In these cases, four or more receiving sensors are employed to
perform ToA multi-lateration.
ToA techniques are capable of resolving location in two-dimensional as well as three-dimensional planes. 3D resolution
can be performed by constructing spherical instead of circular models.
A drawback of the ToA approach is the requirement for precise time synchronization of all stations, especially the
mobile device (which can be a daunting challenge for some 802.11 client device implementations). Given the high
propagation speeds, very small discrepancies in time synchronization can result in very large errors in location accuracy.
As an example, a time measurement error as small as 100 nanoseconds can result in an accuracy error of 30 meters.
ToA-based positioning solutions are typically challenged in environments where a large amount of multipath,
interference, or noise may exist.
RSS LATERATION: Lateration can be performed by using received signal strength (RSS) in place of time as a measuring
source. With this approach, RSS is measured by either the mobile device or the receiving sensor. Knowledge of the
transmitter output power, cable losses, and antenna gains as well as the appropriate path loss model allows you to
solve for the distance between the two stations points.
The accuracy with what RSSI reports typically varies from radio vendor to radio vendor. 802.11 client devices produced
by different silicon manufacturers may report received signal strength using inconsistent metrics. This can result in
degraded and inconsistent location tracking performance.
Location tracking solutions that utilize "network-side" RSSI measurements avoid this potential pitfall when supporting
mobile devices from various manufacturers, since all measurement of RSSI is performed at the network infrastructure,
not at the mobile device.
This is a straightforward approach and is approach most often implemented by vendors of RSS lateration solutions,
since a much higher degree of control is typically exercised over consistency in network infrastructure versus end user
client mobile devices.
NOTE: Pure RSS-based lateration techniques that do not take additional steps to account for attenuation and multipath
in the environment rarely produce acceptable results except in very controlled situations.
This includes those controlled situations where there is always established clear line-of-sight between the mobile device
and the receiving sensors, with little attenuation to be concerned other than free-space path loss and minor impact from
multipath.
ANGLE OF ARRIVAL (ANGULATION):
The Angle of Arrival (AoA) technique, sometimes referred to as Direction of Arrival (DoA), locates the mobile station by
determining the angle of incidence at which signals arrive at the receiving sensor. Geometric relationships can then be
used to estimate location from the intersection of two lines of bearing (LoBs) formed by a radial line to each receiving
sensor, as shown below.
In a two-dimensional plane, at least two receiving sensors are required for location estimation with improved accuracy
coming from at least three or more receiving sensors (triangulation).
PATTERN RECONGNITION:
Location patterning is a technique that is based on the sampling and recording of radio signal behaviour patterns in
specific environments. Location patterning may be implemented totally in software, which can reduce complexity and
cost significantly compared to angulation or purely time-based lateration systems.
Location patterning techniques fundamentally assume the following:

That each potential device location ideally possesses a distinctly unique RF "signature". The closer to reality this
assumption is, the better the performance of the location patterning solution.

That each floor or subsection possesses unique signal propagation characteristics. Despite all efforts at identical
equipment placement, no two floors, buildings, or campuses are truly identical from the perspective of a pattern
recognition RTLS solution.
Although most commercially location patterning solutions typically base such signatures on received signal strength
(RSSI), pattern recognition can be extended to include ToA, AoA or TDoA-based RF signatures as well. Deployment of
patterning-based positioning systems can typically be divided into two phases:


Calibration phase
Operation phase
During the operational phase, solutions based on location patterning rely on the ability to "match" the reported RF
signature of a tracked device against the database of RF signatures amassed during the calibration phase. Because the
database of recorded RF signatures is meant to be compiled during a representative period in the operation of the site,
variations such as attenuation from walls and other objects can be directly accounted for during the calibration phase.
1: CALIBRATION PHASE: During the calibration phase, data is accumulated by performing a walk-around of the target
environment with a mobile device and allowing multiple receiving sensors (AP’s in the case of 802.11 WLANs) to sample
the signal strength of the mobile device (this refers to a "network-side" implementation of location patterning).
This calibration is performed in Prime Infrastructure under RF Calibration Models. A graphical representation of the area
to be calibrated is typically overlaid with a set of grid points or notations to guide the operator in determining precisely
where sample data should be acquired.
At each sample location, the array (Point) or location vector (Linear) of RSS values associated with the calibration device
is recorded into a database known as a radio map or training set. The size of the vector for this sample location is
determined by the number of receiving stations that can detect the mobile device.
Above shows the illustration of this approach, showing multiple sample points and how their respective location vectors
might be formed from detected client RSSI.
Because of fading and other phenomena, the observed signal strength of a mobile device at a particular location is not
static but is seen to vary over time. As a result, calibration phase software typically records many samples of signal
strength for a mobile device during the actual sampling process. Depending on the technique, the actual vector array
element recorded may account for this variation via one or more creative approaches.
A popular, simple-to-implement method is to represent the array element associated with any specific receiver as
the mean signal strength of all measurements of that mobile device made by that receiver sensor for the reported
sample coordinates. The location vector therefore becomes a vector array of mean signal strength elements.
NOTE: Calibration is only supported for CCXv2 and above clients. A minimum of 50 distinct locations and 150
measurements are required to complete a calibration. For every location point saved in the calibration process, more
than one data point is gathered. The progress of the calibration process is indicated by two status bars above the legend,
one for each band.
NOTE: During the calibration you will see the above screen to show its prgress.
2: Operational Phase In the operational phase, a group of receiving sensors provide signal strength measurements
pertaining to a tracked mobile device (network-side reporting implementation) and forwards that information to a
location tracking server (MSE).
The location server uses a complex positioning algorithm and the radio map database to estimate the location of the
mobile device. The server then reports the location estimate to the location client application requesting the positioning
information such as Prime Infrastructure.
RF FINGERPRINTING:
RF Fingerprinting significantly improves the accuracy and precision of traditional signal strength lateration techniques. It
offers the simplicity of an RSSI-based lateration approach with the customized calibration capabilities and indoor
performance previously available only in location patterning solutions.
RF Fingerprinting significantly enhances RSS lateration by using RF propagation models developed from radio
propagation data gathered directly from the target environments. It offers the ability to calibrate an RF model to a
particular environment in a fashion similar to (but more expeditious than) that described for location patterning.
In addition to the use of pre-packaged RF calibration models in Prime Infrastructure, RF Fingerprinting offers the ability
to develop customized models that are based on on-site data collections. This process allows for the overall attenuation
characteristics of the actual environment to be taken into consideration during the derivation of both 2.4 GHz and 5 GHz
path loss models. For each calibration grid location, the physical location coordinates of the calibration client (provided
by the calibration operator) are recorded along with the client RSSI from three or more APs.
The data accumulated during calibration is statistically processed and groomed, then used to build an RF propagation /
calibration model used to predict tracked device RSSI around each AP, where the path loss exponent, shadow fading
standard deviation, and PL1meter values are calculated from the sample calibration data so as to better reflect specific
propagation anomalies present in the environment.
This process consists of several computational cycles where the previously-mentioned parameters are calculated for
each band. The minimum mean square error (MMSE) estimation technique is used to obtain the initial values for the
parameters as shown below, where the path loss exponent is represented by the slope of the applicable MMSE line of
best fit (that is, either default or corrected fit).
NOTE: With RF Fingerprinting, the selection of a location path loss model does not end with MMSE. Rather, MMSE is
used only as the starting point for the selection of finalized parameters for each band, with the ultimate goal being the
optimization of the final path loss model as it pertains to location accuracy. RF Fingerprinting does not rely on good
location performance being a by-product of a RF propagation model that simply provides good coverage mapping.
To locate a mobile client on a map using an RF calibration model, RSS multi-lateration is performed using either a prepackaged RF calibration model or a customized model created during the calibration phase. This process yields the
coordinates of the data point with the highest potential of correctly representing the tracked device's current location.
NOTE: A key advantage with RF Fingerprinting has over Location Tracking is that it does not require proprietary client
hardware or software. It also simplifys the efforts to calibrate things as well.
Cisco RF Fingerprinting offers several key advantages over traditional approaches:





Uses existing AP’s
No proprietary client hardware or software required
Supports popular Wi-Fi active RFID asset tags
Better accuracy and precision
Reduced calibration effort
CCX RADIO MEASUREMENT:
You can configure two parameters that affect client location calculations:


Radio Measurement Requests
Location Calibration
These parameters are supported in Cisco Client Extensions(CCX) v2 and later releases are designed to enhance location
accuracy and timeliness for participating CCX clients. For the location features to operate properly, the APs must be
configured for normal, monitor, or FlexConnect mode. However, for FlexConnect mode, the APs must be connected to
the Cisco WLC.
Radio measurements requests will cause AP’s to issue broadcast radio measurement request messages to clients
running CCXv2 or later. The AP transmit these messages for every SSID over each enabled radio interface at a
configurable interval. In the process of performing 802.11 radio measurements, CCX clients send 802.11 broadcast
probe requests on all the channels specified in the measurement request.
The Location Appliance then uses the uplink measurements based on these requests received to quickly and accurately
calculate the client location. You do not need to specify on which channels the clients are on to measure. The Cisco
WLC, AP, and client automatically determine which channels to use.
The radio measurement feature enables the Cisco WLC to also obtain information on the radio environment from the
client’s perspective (rather than from just that of the AP). In this case, the AP issues unicast radio measurement
requests to a particular CCXv4 or v5 client. The client then sends various measurement reports back to the AP and onto
the Cisco WLC. These reports include information about the radio environment and data used to interpret the location
of the clients.
To prevent the access points and Cisco WLC from being overwhelmed by radio measurement requests and reports, only
two clients per access point and up to 20 clients per Cisco WLC are supported. You can view the status of radio
measurement requests for a particular access point or client as well as radio measurement reports for a particular client
from the Cisco WLC CLI.
The Cisco WLC software improves the ability of the mobility services engine to accurately interpret the location of a
device through a CCXv4 feature called location-based services. The Cisco WLC issues a path-loss request to a particular
CCXv4 or v5 client. If the client chooses to respond, it sends a path-loss measurement report to the Cisco WLC. These
reports contain the channel and transmit power of the client.
NOTE: Non-CCX and CCXv1 clients ignore the CCX measurement requests and do not participate in the radio
measurement activity.
INITIALIZING MSE FOR NETWORK OPERATION:
Once the instillation of the MSE software is complete, the following is a list of mandatory values that need to be entered
in order to finish off the initialization of the MSE.
->
->
->
->
->
->
Hostname (Host name of the
Network interface eth0 (IP
Timezone (Country Timezone
Root password (Changing it
NCS Communication username
NCS Communication password
MSE unit)
Address, Subnet Mask, DNS, Default Gateway)
in UTC, NTP Server)
from default)
NOTE: The NCS credentials are also used by the PI to authenticate their SOAP/XML session with the MSE.
When you first login to the firstly installed MSE, you will be prompted to start the Setup Wizard as per below.
Setup parameters via Setup Wizard (yes/no)
PI MAP SCALING PROCEDURE:
To calibrate / scale your maps correctly in Prime you will need to visit a map page and click on the following icon as per
below.
This will bring up the selected map so that you can scale things properly. It is critical that maps are scaled correct as this
can lead to a number of issues when device tracking / location is required.
EKAHAU CALIBRATION PROCEDURE:
To set the scale of a map
1. Click on the ruler icon to choose that option
2. Left click and hold the mouse button at the first reference point
3. While holding down the left mouse button, drag the pointer to the next reference point and release the left
mouse button
4. Input the size of that line to set the scale for the map
HISTORY PARAMATERS:
You can enable the history tracking of devices by selecting the corresponding devices check box(es). The different
history parameters are as follows:






Wired Stations
Client Stations
Rogue Access Points
Rogue Clients
Interferers
Asset Tags
NOTE: If the history tracking is not enabled, the MSE CAS service is not storing historical data.
ACTIVE RFID TAGS:
The majority of RFID tags are passive RFID tags, comprised basically of a micro-circuit and an antenna. They are referred
to as passive tags because the only time at which they are actively communicating is when they are within relatively
close proximity of a passive RFID tag reader or interrogator.
Another type RFID tag is known as the Active RFID tag, which usually contains a battery that directly powers RF
communication. This onboard power source allows an Active RFID tag to transmit information about itself at great
range, either by constantly beaconing this information to a RFID tag reader or by transmitting only when it is prompted
to do so.
Active tags are usually larger in size and can contain substantially more information (because of higher amounts of
memory) than do pure passive tag designs.
NOTE: The terms beacon and beaconing have been used in the RFID industry for some time, predating the establishment
of the formal 802.11 standards. When an active RFID tag periodically beacons, it is simply transmitting a tag message
(much like any other messages the tag might send) at a set interval.
Despite the use of similar terminology, this should not be confused with an 802.11 Beacon. An 802.11 Beacon is a
management frame that the 802.11 AP (or the beacon sender in an IBSS) transmits to provide time synchronization and
PHY-specific parameters in order to facilitate mobile stations locating and identifying a BSS or IBSS.
FACEBOOK FOR WI-FI:
Cisco MSE “CONNECT FEATURE” has the ability to use the Facebook login page as a front-end portal. In order to
configure Facebook Wi-Fi, you will need to complete the following steps:
Step 1: Assign your Facebook page to one of your locations configured on the MSE.
Step 2: Configure your SSID / WLAN to point to the URL.
The reason why each area is assigned a different portal is so that when wireless clients are in certain locations they can
be presented with a unique front-end login portal for that specific area. This can either be a global page for all areas or
can be designed on a per brand basis.
Using Facebook Wi-Fi as a portal login page provides the following benefits:



Allows the administrator of a facility to enable the facility's Facebook page as a free Wi-Fi hotspot for visitors.
Allows visitors to access free Wi-Fi after accessing the facility’s Facebook page.
Provides insight into a facility's customer base through demographic reports.
The following are the different options to choose for access before authentication:

Allow HTTPs traffic only before authentication and block all the traffic:
To do this, click the sequence number whose Source Port or Dest Port has the value HTTPs. The Access Control
Lists > Rules > Edit page appears and you can select Permit from the Action drop-down list and click Apply.

Allow all the traffic before authentication and intercept HTTP only.
To intercept HTTP, click the sequence number whose Source Port or Dest Port has the value HTTP. The Access
Control Lists > Rules > Edit page appears and you can select Deny from the Action drop-down list and click Apply.
MAINTAINING MSE:
If you lose or forget the Root password for a mobility services engine, follow these steps:
Step 1: When the GRUB screen comes up, press Esc to enter the boot menu.
NOTE: The connection must be made over the console port, not by connecting a keyboard, mouse, monitor to the unit.
Step 2: Press e to edit.
Step 3: Navigate to the line beginning with "kernel," and press e.
At the end of the line enter a space and the number one (1). Press Enter to save this change.
Step 4: Press b to begin boot sequence. At the end of the boot sequence, a shell prompt appears.
NOTE: The shell prompt does not appear if you have set up a single user mode password.
Step 5: You can change the root password by entering the passwd command.
Step 6: Enter and confirm the new password.
Step 7: Restart the machine.
NOTE: If you forget the GRUB password, and you cannot login and you will need to contact TAC to arrange for an RMA.
INTEGRATING MSE WITH PRIME INFRASTRUCTURE:
In order to integrate MSE with PI you need the following information to entre in.
Step 1: Login to PI with the root credentials in the Root virtual domain.
Step 2: Choose (Services > Mobility Services > Mobility Services Engines) to display the Mobility Services page on PI.
Step 3: From the Select a command drop-down list, choose Add Mobility Services Engine , and click Go .
The Add Mobility Services Engine page will then appear.
Step 4: Enter the following information:





Device Name – The name of the MSE that was assigned to it during its build process.
IP Address – The IP address of the mobility service engine that was assigned to it during its build process.
Contact Name (optional) – The mobility service engine administrator.
Username – The default username is admin. This is the Prime Infrastructure communication username
configured on the MSE during its build process.
Password – The default password is admin. This is the Prime Infrastructure communication username
configured on the MSE during its build process
NOTE: An MSE is only added if a valid IP address is entered. The Device Name helps you distinguish between devices if
you have multiple mobility services engines, but it is not considered when validating an MSE’s connectivity.
Step 5: Click Next . Prime Infrastructure will then automatically synchronize the selected elements with the MSE.
After the synchronization, the MSE License Summary page appears. You can use the MSE License Summary page to
install a license, add a license, remove a license, install an activation license, and install service license.
NOTE: After version 7.5 and onwards you cannot enable both CAS and wIPS on the same unit. They each require a
deticated MSE unit to function correctly.
Step 6: Once you have completed the above steps then you can finish off configuring the MSE for the various things you
want to assign to it such as the following:
TRACKING OF:

Wired Clients

Wireless Clients

Rogue Access Points (This excludes Adhoc Rogue Aps)

Rogue Clients

Interferers

Active RFID Tags
HISTORY TRACKING OF:

Wired Stations

Client Stations

Rogue Access Points

Rogue Clients

Interferers

Asset Tags
Step 7: After configuring your MSE for tracking and history parameters, the next step is to assigning maps. Click next
and the Map Assignment page will appear. The Assign Maps page shows the following information:

Name

Type (building, floor, campus)

Status
You can see the required map type by selecting either All, Campus, Building, Floor Area, or Outdoor Area from the Filter
option available on the page. Once you have made your selection, to synchronize a map, select the Name check box,
and click Synchronize.
NOTE: Upon synchronization of the network designs, the appropriate controllers that have APs assigned on a particular
network design are synchronized with the MSE automatically.
NOTE: The Assigning Maps page is available only if you select CAS as one of the services to be enabled on the MSE.
MSE INFORMATION:
Below are the timers that the MSE will use to communicate with either PI or the WLC and its protocols.
NMSP Parameters
Parameter
Echo Interval
Description
How frequently an echo request is sent from a mobility services engine (MSE) to a WLC. The
default value is 15 seconds. Allowed values range from 1 to 120 seconds.
Note: If a network is experiencing slow response, you can increase the values of the echo
interval, neighbor dead interval, and the response timeout values to limit the number of failed
echo acknowledgements.
Neighbor Dead Interval
The number of seconds that the mobility services engine (MSE) waits for a successful echo
response from the WLC before declaring the neighbor dead. This timer begins when the echo
request is sent.
The default value is 30 seconds. Allowed values range from 1 to 240 seconds.
Note: This value must be at least two times the echo interval value.
Response Timeout
How long the mobility services engine waits before considering the pending request as timed
out. The default value is 1 second. Minimum value is 1. There is no maximum value.
Retransmit Interval
Interval of time that the mobility services engine waits between notification of a response
timeout and initiation of a request retransmission. The default setting is 3 seconds. Allowed
values range from 1 to 120 seconds.
Maximum Retransmits
The maximum number of retransmits that are sent in the absence of a response to any request.
The default setting is 5. Allowed minimum value is 0. There is no maximum value.
6: DESIGN AND IMPLEMENT FLEXCONNECT ARCHITECTURE: 12% WEIGHTING ON THE EXAM
FlexConnect AP’s are designed for remote sites to be managed by a central WLC. FlexConnect AP’s can switch client data
traffic locally instead of tunnelling it via CAPWAP back to the WLC. Additionally, they can also perform client
authentication locally even after their connection to the WLC is lost.
FLEXCONNECT AP MODES:
Connected Mode: Connected mode is the normal operating mode of a FlexConnect AP and means that the AP is
currently registered with its WLC. Just like with a Local Mode AP, if so desired one or more WLANs can be mapped to
the same local 802.1Q VLAN.
Stand Alone Mode: Whenever a FlexConnect AP disassociates from a controller, it moves to Stand Alone Mode. This
disassociation is usually caused by the loss of communication from the AP itself to the WLC.

WLAN’s that are that are centrally switched will have their clients disassociated when moving into Stand Alone
Mode by the AP. However, FlexConnect AP’s will continue to serve clients part of a locally switched WLAN’s in
Stand Alone Mode. I.e. if the AP is offering another WLAN’s etc.

When the FlexConnect AP re-joins the WLC (or a secondary WLC) and goes back to Connected Mode, all clients that
were disconnected from a centrally switched WLAN and are allowed to authenticate again if they reattempt too.

The WLC can send multicast packets in the form of unicast or multicast packets to the AP for normal Local Mode
AP’s. In FlexConnect mode, the AP can only receive multicast packets only in unicast form which are encapsulated
in the CAPWAP header.

FlexConnect supports Client Mobility supports up to 100 AP’s within a FlexConnect AP Group which is the maximum
AP count for a FlexConnect Group for a 7510 and only 25 AP’s for a 5508 WLC.

Since 8.0, AP’s no longer needs to reboot when changing from Local to FlexConnect mode, but when they are
changed from FlexConnect back Local they will.

When an AP boots up, it looks for a WLC. If it finds one, it joins the WLC, downloads the latest software image and
configuration from the WLC, and initializes the radio. It saves the downloaded configuration in non-volatile memory
for use in Stand Alone Move.

When a FlexConnect AP enters Stand Alone Mode, WLANs that are configured for open, shared, WPA-PSK, or
WPA2-PSK authentication enter the “local authentication, local switching” state and continue to allow new client
authentications. This is possible because the configuration is saved on the AP’s themselves.

This is also true for WLANs that are configured for 802.1X, WPA-802.1X, WPA2-802.1X, or CCKM, but these
authentication types require that an external RADIUS server be configured on the WLAN.

For web-authentication WLANs, existing clients are not disassociated, but the FlexConnect AP will stop sending
beacons only when the number of associated clients reaches zero (0). It also sends disassociation messages to new
clients associating to web-authentication WLANs.

Controller-dependent activities, such as (NAC) and web authentication (guest access), are disabled, and the AP does
not send any (IDS) reports to the WLC.

Most radio resource management (RRM) features (such as neighbour discovery; noise, interference, load, and
coverage measurements; use of the neighbour list; and rogue containment and detection) are disabled when in
Stand Alone Mode, although DFS is still enabled.
FLEXCONNECT DEPLOYMENT OPTIONS:
FlexConnect AP’s send all authentication messages to the controller regardless of the WLAN authentication type (Local /
Central). This is so that client information can be centrally viewed at the WLC. If the WLAN is locally switched it’ll then
switch the client data packets locally or if the WLAN is centrally switching it’ll send the clients data packets to the WLC
via its CAPWAP tunnel.

With respect to client authentication (Open, Shared, EAP, Web Authentication, NAC) and data packets, the
WLAN can be in any one of the following states depending on the configuration and state of controller
connectivity:
1. Central Authenticated / Central Switched: In this deployment, the controller handles client
authentication, and all client data is tunnelled back to the controller via a CAPWAP tunnel. This state is
valid only in connected mode.

Authentication Down / Switch Down: In this sub-state, a WLAN that is Centrally Authenticated /
Central Switched will disassociated existing clients and stops sending beacon and responding to
probe requests. This state is possible in either standalone mode or connected mode.
2. Central Authenticated / Local Switched: In this deployment, the WLC handles client authentication, and
the FlexConnect AP switches client data packets locally via its trunk port.
After the client authenticates successfully, the WLC sends a configuration command with a new payload
to instruct the FlexConnect AP to start switching data packets locally.
This message is sent per client. This state is applicable only in Connected Mode.

Authentication Down / Switch Up: In this sub-state, the AP rejects any new clients trying to
authenticate, but it continues sending beacon and probe responses to keep existing clients alive. This
state is valid only in Stand Alone Mode.
3. Local Authenticated / Local Switched: In this deployment, the FlexConnect AP handles client
authentication and switches client data packets locally. This continues whether the AP is in either
standalone mode or connected mode.
NOTE: For the FlexConnect Local Switching, Central Authentication deployments, if there is a passive client with a static
IP address, it is recommended to disable the Learn Client IP Address feature under the WLAN > Advanced tab.
NOTE: Local Authentication can only be enabled on a Local Switched WLAN. You cannot have a Local Authenticated
WLAN with Central Switching.
DEPLOYMENT CONSIDERATIONS:
WAN LINK:

Latency: WAN latencies should not be more than 100ms. The AP will send heartbeat messages to the WLC once
every thirty seconds by default. If a heartbeat response is missed, the AP sends five successive heartbeats (one
per second) to determine whether connectivity still exists. If connectivity is lost, the FlexConnect AP switches to
Standalone Mode.
Also, the AP & WLC exchange echo CAPWAP packet to check their connectivity. If the echo CAPWAP packet
response is missed, the AP sends five successive echo CAPWAP packets (every three seconds) to determine
whether the connectivity still exists. Again, if the connectivity is lost, the FlexConnect AP switches to Stand Alone
Mode.

Path MTU: An MTU no smaller than 500 bytes is required.

WAN Link Bandwidth: Bandwidth should be at least 128 kbps for deployments when up to 8x APs are being
deployed. If more than eight APs are deployed, proportionally more bandwidth will be required.
ROAMING:
When a FlexConnect AP is in Connected Mode, all client probes, association requests, 802.1x authentication requests,
and corresponding response messages are exchanged between the AP and the WLC via the CAPWAP control plane. This
is true for open, static WEP and WPA PSK-based WLANs even though CAPWAP connectivity is not required to use these
authentication methods when the AP is in standalone mode.

WPA2: WPA2 improves roaming times by introducing key caching capabilities, based on the IEEE 802.11i. Cisco
created an extension to this specification called Proactive Key Caching (PKC). PKC today is supported only by the
Microsoft Zero Config Wireless supplicant and the Funk (Juniper) Odyssey client. Cisco CCKM is also compatible
with WPA2.

Cisco Centralized Key Management (CCKM): CCKM is a Cisco-developed protocol where the WLC caches the
security credentials of CCKM-capable clients and forwards those cached credentials to other APs that are part of
the same FlexConnect Group.
When a client roams and associates with another AP within the same FlexConnect Group, their cached credentials
have already been copied, which allows the client to re-associate and authenticate in a two-step process, thus
eliminating need for full authentication back to the AAA server. This significantly reduces roaming times.

FlexConnect Groups: Are required for CCKM/OKC fast roaming to work with FlexConnect AP’s. Fast roaming is
achieved by caching a derivative of the master key from a full EAP authentication so that a simple and secure key
exchange can occur when a wireless client roams to a different AP.
This feature prevents the need to perform a full RADIUS EAP authentication as the client roams from one AP to
another. The FlexConnect AP’s need to obtain the CCKM/OKC cache information for all the clients that might
associate so they can process it quickly instead of sending it back to the controller.
As an example, if you have a controller with 300 AP’s and 100 clients that might associate, sending the CCKM/OKC
cache for all 100 clients is not practical. If you create a FlexConnect Group comprising a limited number of APs (for
example, you create a group for four APs in a remote office), the clients roam only among those four APs, and the
CCKM/OKC cache is distributed among those four APs only when the clients associate to one of them.

Layer 2 Switch CAM Table Updates: When a client roams from one AP to another on a locally-switched WLAN,
FlexConnect AP’s does not announce to a Layer 2 switch that the client has changed ports. The switch will not
discover that the client has roamed until the client performs an ARP request for its default router. This behaviour,
while subtle, can have an impact on roaming performance.
NOTE: A client that roams (for a given local switched WLAN) between FlexConnect AP’s on different WLC’s that map the
WLAN to a different VLAN/subnet will renew their IP Addresses to ensure that they have an appropriate address for the
network to which they have roamed. This will cause issues for wireless IP Phones.
FLEXCONNECT LOCAL RADIUS AUTHETNICATION:
As part of FlexConnect AP Groups, you can configure a primary or secondary or both Local Radius servers. This can be
used so that FlexConnect AP’s can continue to support 802.1X when in Stand Alone Mode or with local authentication
WLAN’s.
NOTE: Only local Radius Authentication is supported and not Radius Accounting.
With Local Radius configured, clients can continue to perform 802.1X authentication even after the FlexConnect APs
lose connectivity with the WLC. As long as the RADIUS/ACS server is reachable from the AP’s, wireless clients will
continue to authenticate and access wireless services. If the RADIUS/ACS is located at the same site, then clients will
authenticate and access wireless services even during a branch sites WAN outage.
When FlexConnect AP’s are registered to the WLC, the WLC uses its primary RADIUS servers and accesses them in the
order specified on the RADIUS Authentication Servers page within the WLAN. However, to support 802.1X EAP
Authentication, FlexConnect AP’s Standalone Mode need to have their own backup RADIUS server(s) specified to
authenticate clients. This is configured under the FlexConnect AP Group.
NOTE: A WLC does not use a backup RADIUS server. The WLC uses the backup RADIUS server only in Local Authentication
mode.
You can configure a backup RADIUS server for individual FlexConnect APs in standalone mode by using the controller CLI
or for groups of FlexConnect APs in standalone mode by using either the GUI or CLI. A backup server configured for an
individual AP overrides the backup RADIUS server configuration for a FlexConnect AP Group.
VLAN MAPPINGS:
VLAN ACL’s: VLAN ACL’s are the most commonly used ACL and it lets you control client traffic that is sent in and out of
the VLAN. These are configured on the FlexConnect AP Groups.
Additionally, these can also be configured on a per AP basis as per below.
These ACL’s can be specified which direction they are applied. Ingress (Towards the wireless client), Egress (Towards the
LAN), both or none.
WEBAUTH ACL’s: WebAuth ACL is used in the case of a WebAuth/WebPassthrough Service Set Identifier (SSID) which
has been enabled for flexconnect local switching. This is used as a pre-authentication ACL and allows client traffic to the
redirect server. Once the redirection is complete and the client is in RUN state, the ACL stops to take it into effect.
WebAuth ACL can be applied either at the WLAN level, AP level or flexconnect group level. An AP specific ACL has the
highest priority, whereas the WLAN ACL has the lowest.
SPLIT TUNNEL ACL’s: Split Tunnelling ACL's are used with centrally switched SSID's when some of the client traffic needs
to be sent over locally. The Split Tunnelling functionality is also an added advantage for Office Extend AP (OEAP) setup
where clients on a Corporate SSID can talk to devices on a local network (printers, wired machine on a Remote LAN Port,
or wireless devices on a Personal SSID) directly once they are mentioned as part of the split tunnel ACL.
FLEXCONNECT AP UPGRADE FEATURE:
When this feature is enabled under the FlexConnect AP Group and is initialized, one AP of each model type will firstly try
to download the upgrade image over the WAN Link. These are known as a Master AP. A Master AP can either be
manually selected within it FlexConnect AP Group or by default the Auto Election process will be used.
The Auto Election process will select the AP that has the lowest MAC address value. This Auto Election process happens
when the FlexConnect AP Upgrade feature is initialized and no Master AP has been predefined.
After the image has been downloaded by the Master AP, the remaining AP’s then download the upgrade image from
their respective model Master AP using the pre-image download feature over the local network, which reduces the
WAN consumption.
These AP’s are known as slave AP’s which make several attempts to download the image from the Master AP as the
Master AP can only concurrently upload the image to 3x slave AP’s. The maximum number of attempts is 63 which is
configurable under the FlexConnect AP group. Once this threshold is reached, then the slave AP will try and download
their image directly from the WLC instead.
OE OFFICE-EXTEND OVERVIEW:
Cisco’s “Office-Extend” solution allows you to extend a corporate network into a teleworker’s place or into employee’s
home without compromising security policies.
Office-Extend AP’s (OEAP) can sit behind any public internet device (Home ADSL router, etc) allowing it to extend a
corporate WLAN on to it. It also has the ability of defining a locally significant WLAN (personal) where other home users
can use the same AP to go to public internet without going through the corporate network.
Cisco has released a special AP series (OEAP 600 series) which has full a/g/n (dual band) capability with 4 LAN ports. Out
of these four ports, one port is for Remote-LAN where you can extend one of your wired VLAN’s of your corporate on to
this port. You can also connect a hub/switch to this Remote-LAN port & connect up to 4 wired devices). The other 3
ports are for local LAN site connectivity.
To extended the corporate WLAN, a maximum of 3 WLAN’s can be extended & maximum of 15 clients can be joined.
Configuration wise OEAP is meant for “Zero Touch” deployment where it only requires the WLC IP to be pre-configured
on it.
In addition to the OEAP 600 series, AP (1040/1130/1140/3502/3602/2602/2702) series AP’s can be convert into OEAP
mode. This will allow extending corporate WLAN environment to remote sites, employee’s home environment (Except
wired LAN extension which is only in OEAP 600). As it allows creating locally significant SSID other home users can use
the same AP to connect & do their work. Cisco introduced this feature in WLC 7.0 code and it works with 5508, WiSM2
& 2500/7500 series controllers.
The OEAP (which has been pre-configured with the WLC IP) went connected to a public internet service; it will create an
encrypted DTLS tunnel between the AP & WLC. Then the selected corporate SSID will be advertised through to this
OEAP. It also allows the end user to create locally significant SSID for their home use & that traffic is not going via DTLS
tunnel.
CONFIGURING OFFICE-EXTEND:
Below are the steps involved in order to configure an OEAP prior deployment:
1: Register with the WLC: The first step is it to connect the AP into the network in normal local mode & get it register to
the WLC. Once registered, you can select this AP in controller GUI & change its mode to “FlexConnect” and apply.
2: Specify Static WLC Details: In order for the AP to always go to this specific WLC (normally who has a publicly
reachable IP address or WLC’s management IP address NAT to Public IP) you need to configure the WLC Name & IP
Address on the AP’s “High Availability” tab.
3: Enable Office Extend Mode: Once the AP registers back to controller, under the “FlexConnect” tab & you can enable
“Office Extend” check box. Once you tick “Enable OfficeExtend AP” check box it will prompt “Do you want to enable
encryption?” & “Do you want to disable Rouge Detection?” You need to click “OK” to both of these as best practices.
NOTE: If you select cancel all traffic will be NOT be DTLS encrypted.
4: OEAP NAT Settings (Optional): If your WLC does not have a publicly reachable IP then you need to NAT the IP to
where controller management IP is reachable. In that case you need to enable NAT on WLC management interface &
map a NAT IP to it.
5: Create AP Group: By default, only the first 3 WLANs (WLAN ID’s with numbers less than 8) will be advertised to OEAP.
By creating an AP group (WLAN -> Advanced -> AP Groups) you can control what particular WLAN’s will be advertised.
NOTE: If you want to create locally significant SSID or WLAN for home users, you can simply do this by accessing OEAP’s
GUI via its IP Address on the local network. Default username & password would be cisco/Cisco (In OEAP 600 series it is
admin/admin).
NOTE: Only for OEAP 600 series AP’s the WLAN must have the same Layer 2 settings for both WPA & WPA2.
CONFIGURING OFFICE-EXTEND SPLIT TUNNELLING:
Split tunnelling for OEAP600 series AP’s is available on WLC 7.5.x onwards. This will allow certain traffic to be locally
switched such as printer access & all other traffic to centrally switch from an OEAP. OEAP 600 series are limited to just
Printing services & forwarded well known printer ports traffic back to local subnet behind OEAP.






IPP (port :631)
PDL (port :9100)
MFP (port :9303)
LPD, LPR (port :515)
PSUS4 (port :34443)
Generic printer server (port :35)
The Packet Flow Process:
1: AP inspects the traffic sent by the client to the corporate network for the well-known printers.
2: When the client is configured with a gateway, it sends all packets to the destination MAC address of the gateway. In
this case, when the client is connected to the corporate SSID with the destination MAC address of the gateway, the SSID
tries to connect to the printer 192.168.1.100.
3: The AP finds a match for the printer port and sends out an Address Resolution Protocol (ARP) request on the local
network for the destination IP address of the printer.
4: When it receives a reply, it changes the destination of the MAC address. It changes from the gateway's MAC address
to the printer's MAC address and forwards it to the local network.
5: The AP bridges back the reply traffic from the printer to the client.
Below are the steps involved in order to configure Split Tunnelling for OEAP:
1: Enable Split Tunnelling Globally: You must enable OEAP Split Tunnelling globally before enabling it on a per WLAN
basis.
(WLC) >config network oeap-600 split-tunnel enable
2: Enable Split Tunnelling on the WLAN: Then you need to go to WLAN-Advanced settings where you can enable this
feature for a specific WLAN.
(WLC) >config wlan split-tunnel 1 enable
(WLC) >config wlan split-tunnel 2 enable
3: Verify Configuration: The final step is to verify that you have enabled all the correct parameters.
(WLC) >show network summary
oeap-600 dual-rlan-ports ...................
oeap-600 local-network .....................
oeap-600 Split Tunneling (Printers).........
Split Tunnel (Printers).....................
Enable
Enable
Enable
Enabled
7: IMPLEMENT CONTROLLER & AP HIGH AVALIABILITY: 10% WEIGHTING ON THE EXAM
LINK AGGREGATION (LAG):
Link Aggression on a WLC bundles all of the its distribution system ports into a single port channel, thus reducing
required IP address assignment. When LAG is enabled, the system dynamically manages port redundancy and load
balances AP’s transparently to the user.
If any of the WLC ports fail, traffic is automatically migrated to one of the other remaining ports. As long as at least one
WLC port is functioning, the system continues to operate, AP’s remain connected to the network, and wireless clients
continue to send and receive data.
NOTE: WLC’s do not send CDP messages via any LAG interfaces.
NOTE: It’s recommended you enable link aggregation configuration on the WLC’s before you enable the port channel in
the infrastructure switches.
RESTRICTIONS FOR LINK AGGREGATION:
With LAG on WLC’s there are some restrictions to keep in mind. Below is a list of these restrictions:

You can bundle all eight ports on a Cisco 5508 Controller into a single LAG link.

Terminating on two different modules within a single Catalyst 6500 series switch provides redundancy and ensures
that connectivity between the switch and the WLC is maintained when one module fails. The WLC’s port 1 is
connected to Gigabit interface 3/1, and the WLC’s port 2 is connected to Gigabit interface 2/1 on the Catalyst 6500
series switch. Both switch ports are assigned to the same channel group.

LAG requires the EtherChannel to be configured for 'mode on' on both the WLC and the switch.

Once the EtherChannel is configured as on at both ends of the link, the Catalyst switch should not be configured for
either Link Aggregation Control Protocol (LACP) or Cisco proprietary Port Aggregation Protocol (PAgP) but be set
unconditionally to LAG.
Because no channel negotiation is done between the WLC and the switch, the WLC does not answer to negotiation
frames and the LAG is not formed if a dynamic form of LAG is set on the switch. Additionally, LACP and PAgP are
not supported on the WLC.

If the recommended load-balancing method cannot be configured on the Catalyst switch, then configure the LAG
connection as a single member link or disable LAG on the WLC.

You cannot configure the WLC’s ports into separate LAG groups. Only one LAG group is supported per WLC.
Therefore, you can connect a WLC in LAG mode to only one neighbour device.

When you enable LAG or make any changes to the LAG configuration, you must immediately reboot the WLC.

When you enable LAG, you can configure only one AP-manager interface because only one logical port is needed.
LAG removes the requirement for supporting multiple AP-manager interfaces.

When you enable LAG, all dynamic AP-manager interfaces and untagged interfaces are deleted, and all WLANs are
disabled and mapped to the management interface. Also, the management, static AP-manager, and VLAN-tagged
dynamic interfaces are moved to the LAG port.

Multiple untagged interfaces to the same port are not allowed.

When you enable LAG, you cannot create interfaces with a primary port other than 29.

When you enable LAG, all ports participate in LAG by default. You must configure LAG for all of the connected ports
in the neighbour switch.

When you enable LAG, if any single link goes down, traffic migrates to the other links.

When you enable LAG, only one functional physical port is needed for the WLC to pass client traffic.

When you enable LAG, AP’s remain connected to the WLC until you reboot the WLC, which is needed to activate
the LAG mode change, and data service for users continues uninterrupted.

When you enable LAG, you eliminate the need to configure primary and secondary ports for each interface.

When you enable LAG, the WLC will send packets out on the same port which it received them. If a CAPWAP packet
from an AP enters the WLC on physical port 1, the WLC removes the CAPWAP wrapper, processes the packet, and
forwards it to the network on physical port 1. This may not be the case if you disable LAG.

When you disable LAG, the management, static AP-manager, and dynamic interfaces are moved to port 1.

When you disable LAG, you must configure primary and secondary ports for all interfaces.

When you disable LAG, you must assign an AP-manager interface to each port on the WLC. Otherwise, AP’s are
unable to join.

Cisco 5500 Series WLC’s support a single static link aggregation bundle.

LAG is typically configured using the Startup Wizard, but you can enable or disable it at any time through either the
GUI or CLI.

When you enable LAG on Cisco 2500 Series WLC to which the direct-connect AP is associated, the direct connect AP
is disconnected since LAG enabling is still in the transition state. You must reboot the WLC immediately after
enabling LAG.

In 8500 when there are more than 1000 APs joining WLC flapping occurs, to avoid this do not add more than 1000
AP’s on a single catalyst switch for Capwap IPv6.
CONFIGURING LINK AGGREGATION (GUI)
Step 1: Choose Controller > General to open the General page
Step 2: Set the LAG Mode on Next Reboot parameter to Enabled
Step 3: Save the WLC config
Step 4: Reload the WLC
Step 5: Assign WLAN to the appropriate VLAN
CONFIGURING LINK AGGREGATION (CLI)
Step 1: Entre the “config lag enable” command on the WLC to enable LAG
Step 2: Save the WLC config
Step 3: Reload the WLC
VERIFYING LINK AGGREGATION SETTINGS (CLI)
To verify your LAG settings, enter this command:
show lag summary
Information similar to the following appears: LAG Enabled
SWITCH PORT CONFIGURATION FOR LAG:
The WLC’s neighbouring device must also be properly configured to support LAG. Below is an example switch port
configuration:
Interface GigabitEthernet 1/0/1
switchport
channel-group 1 mode on
no shutdown
Interface port-channel 1
switchport
switchport trunk encapsulation dot1q
switchport trunk native vlan 10
switchport trunk allowed vlan 99
switchport mode trunk
no shutdown
LAG vs MULTIPLE AP-MANAGER INTERFACES:
5500 WLC’s have no restrictions on the number of AP’s per port, but Cisco recommends using LAG or multiple APmanager interfaces on each Gigabit Ethernet port to automatically balance the load.
The following factors should be considered as part of the decision-making process on which method to use if your
controller is set for Layer 3 operations:

With LAG, all of the WLC ports need to connect to the same neighbour switch. If the neighbour switch goes down,
the WLC loses connectivity.

With multiple AP-manager interfaces, you can connect your ports to different neighbour devices. If one of the
neighbour switches goes down, the WLC still has connectivity. However, using multiple AP-manager interfaces
presents certain challenges when port redundancy is a concern.
AUTO ANCHOR CONTROLLER REDUNDANCY:
This feature performs an automatic ping function that enables a foreign WLC to proactively ping auto anchor wlc’s to
verity control and data path connectivity. In the event of failure or an active auto anchor becomes unreachable, the
foreign WLC does the following:



Automatically detects that the anchor has become unreachable.
Automatically disassociates any wireless clients that were previously associated with the unreachable anchor.
Automatically re-associates wireless client(s) to an alternate anchor WLC.
With guest N+1 redundancy, two or more anchor WLCs can be defined for a given guest WLAN. Keep in mind the
following in regards to guest N+1 redundancy:

A given foreign WLC load balances wireless client connections across the list of anchor WLC configured for a guest
WLAN. There is currently no method to designate one anchor as primary with one or more secondary anchors.

Wireless clients that are associated with an anchor WLC that becomes unreachable are re-associated with another
anchor defined for the WLAN. When this happens, assuming web authentication is being used, the client is
redirected to the web portal authentication page and required to re-submit their credentials.
CONFIGURTING AP FALL-BACK:
Unlike Hot Standby Router Protocol (HSRP) standby, AP fall-back disrupts wireless service while the AP fails over or
when they fail back to the original WLC. Remember that once an AP joins a WLC, the AP is only programmed to leave
that WLC if the following occurs:

The AP loses responses from its keep lives to the WLC.

If you reset the AP via the WLC.

The AP receives a notification, via the mobility group members update from the current WLC, that one of its’s
configured WLC’s (Primary/Secondary/Tertiary) is up, and the AP is currently joined to an un-configured WLC with
AP fall-back enabled.
NOTE: The AP only perform an AP fall-back when it has joined an unconfigured WLC and one of the configured WLC’s
(Primary/Secondary/Tertiary) comes back online. The AP will not switch back from a secondary WLC to the primary WLC
if it is currently joined to the secondary WLC. This is because the secondary WLC is one of the configured WLC’s.
When the AP is joined to an unconfigured WLC and it is notified that one of its configured WLC’s is up and available via
the mobility group members, it immediately leaves the current WLC and joins that WLC.
AP PRIORTIZATION:
Each WLC has a defined number of communication slots for AP’s to join and register. When multiple WLC’s with unused
AP communication slots are deployed on the same network and one WLC fails, the dropped AP’s automatically poll for
unused WLC slots and associate accordingly.
The following are some guidelines for configuring failover priority for AP’s:




You can configure your wireless network so that the backup WLC recognizes a join request from a higher-priority
AP and if necessary disassociates a lower-priority AP as a means to provide an available port.
Failover priority is not in effect during the regular operation of your wireless network. It takes effect only if there
are more association requests after a WLC failure than there are available backup WLC ports.
To configure this feature, you must enable failover priority on your network and assign priorities to the individual
AP’s.
By default, all AP’s are set to priority level 1, which is the lowest priority level. Therefore, you need to assign a
priority level only to those AP’s that warrant a higher priority.
CONFIGURE FAILOVER PRIORITY FOR AP’s (GUI)
Step 1: Wireless > Access Points > Global Configuration to open Global AP Failover Priority drop-down list,
choose Enable. Default setting is disabled.
Step 2: Once enabled, then you can go to any AP and under the High Availability tab the drop-down box for the AP
Failover Priority allows you to select one of the following options:




LOW: Assigns the AP to the level 1 priority, which is the lowest priority level. This is the default value.
MEDIUM: Assigns the AP to the level 2 priority.
HIGH: Assigns the AP to the level 3 priority.
CRITICAL: Assigns the AP to the level 4 priority, which is the highest priority level.
CONFIGURE FAILOVER PRIORITY FOR AP’s (CLI)
Step 1: You must enable AP Failover priority by using this command: config network ap-priority {enable | disable}
Step 2: Once enabled, can set induvial AP’s priority using the command: config ap priority {1 | 2 | 3 | 4} Cisco_AP
CONFIGURE LEGACY PRIMARY / SECONDARY & TERTIARY WLC:
Setting the Primary / Secondary / Tertiary WLC values is on a per AP basis and is under the High Availability tab.
CONFIGURE WLC STATEFUL SWITCHOVER ON AireOS(SSO):
In an HA architecture, one WLC is configured as the primary unit and another WLC as the secondary unit. After you
enable HA, both the primary and secondary WLC’s are rebooted. During the boot up process, the role of the primary
WLC is negotiated as Active and the role of the secondary WLC as Standby-Hot.
After a switchover event, the secondary WLC becomes the active unit and the primary WLC becomes the standby-hot
unit. After subsequent switchovers, the roles are interchanged between the primary and the secondary WLC’s. The
reason for switchovers are either because of manual trigger or a network failure.
During an AP SSO, all the AP sessions are statefully switched over and all the clients are reauthenticated and
reassociated with the new active WLC except for the locally switched clients connected to FlexConnect mode AP’s.
The Standby-Hot WLC continuously monitors the health of the Active WLC through a direct wired connection over a
dedicated port known as the “Redundancy Port”. Both the WLC’s share the same configurations, including the IP
address of the management interface, however they also do have their own unique IP address as well.
Clients that are not in the RUN state are removed after the switchover. During the stateful switchover of a client (Client
SSO), the information of the client is synchronized with the standby unit when the client is associated with the WLC.
Clients that are fully authenticated, that is, clients that are in the RUN state, are synchronized with the peer WLC.
The output of the show ap join stats summary command displays the status of the AP’s based on whether the AP joined
the WLC or it was synchronized from Active WLC.
One of the following statuses is displayed:

Synched: The AP joined the WLC before the SSO event.

Connected: The AP joined the WLC after the SSO event.

Joined: The AP re-joined the WLC, or a new AP has joined the WLC after the SSO event.
The output of the show redundancy summary command displays the bulk synchronization status of AP’s and clients
after the pair-up of active and standby units occurs. The values are:

Pending: Synchronization of AP’s and the corresponding client’s details from the active to standby units is yet to
begin.

In-progress: Synchronization of AP’s and the corresponding client’s details from the active to standby controller has
begun and synchronization is in progress.

Complete: Synchronization is complete and the standby unit is ready for a switchover to resume the services of the
active unit.
NOTE: In Release 7.3.x, AP SSO is supported, but client SSO is not supported, which means that after an HA setup that
uses Release 7.3.x encounters a switchover, all the clients associated with the controller are de-authenticated and forced
to reassociate.
HIGH AVAILABLILITY GUIDELINES:
Below is a list of recommended guidelines from Cisco for HA:

Do not pair two controllers of different hardware models. If you try to pair different model types, the higher
controller model becomes the active controller and the other controller goes into maintenance mode.

Do not pair two WLC’s on different WLC software releases. If they are paired, the WLC with the lower redundancy
management address becomes the Active unit and the other unit goes into maintenance mode.

All download file types, such as image, configuration, web-authentication bundle, and signature files are
downloaded to the Active unit first and then pushed to the Standby-Hot unit.

Certificates should be downloaded separately on each controller before they are paired.

You can upload file types such as configuration files, event logs, crash files, and so on, from the Standby-Hot unit
via the GUI or CLI of the Active unit. You can also specify a suffix to the filename to identify the uploaded file.

To perform a peer upload, use the service port. In a management network, you can also use the redundancy
management interface (RMI) that is mapped to the redundancy port or RMI VLAN, or both, where the RMI is the
same as the management VLAN.
NOTE: that the RMI and the redundancy port should be in two separate Layer2 VLANs, which is a mandatory
configuration.

If the WLC’s cannot reach each other through the redundant port and the RMI, the primary unit becomes Active
and the Standby-Hot unit goes into the maintenance mode.
NOTE: To achieve HA between two WiSM2, the WLC’s should be deployed on a single 6500 chassis, or on multiple chassis
using a virtual switching system (VSS) and extending a redundancy VLAN between the multiple chassis.
NOTE: When the RMIs for two WLC’s have paired are mapped to the same VLAN and connected to same Layer3 switch
stop working, the standby controller is restarted.
REDUNDANCY MANAGEMENT INTERFACE:
The Active and Standby-Hot WLC use the RMI (Redundancy Management Interface) to check the health of its peer WLC
and the default gateway of the management interface through network infrastructure.
The RMI is also used to send notifications from the Active WLC to the Standby-Hot WLC if a failure or manual reset
occurs. The Standby-Hot unit uses the RMI to communicate to the syslog, NTP/SNTP server, FTP, and TFTP server.
NOTE: It is mandatory to configure the IP addresses of the Redundancy Management Interface and the Management
Interface in the same subnet on both the primary and secondary units.
REDUNDACY PORT:
The redundancy port is physical dedicated port used for configuration, operational data synchronization, and role
negotiation between the primary and secondary units that make up the HA pair.
The redundancy port checks for peer reachability by sending UDP keepalive messages every 100 milliseconds by default
from the Standby-Hot unit to the Active unit. If a failure of the Active unit occurs, the redundancy port is used to notify
the Standby-Hot unit.
If an NTP/SNTP server is not configured, the redundancy port performs a time synchronization from the Active unit to
the Standby-Hot unit.
NOTE: With a WiSM2, the redundancy VLAN must be configured on the Cisco Catalyst 6000 Supervisor Engine because
there is no physical redundancy port available on Cisco WiSM2.
The redundancy port and the redundancy VLAN (WiSM2) are assigned an automatically generated IP address in which
the last two octets are obtained from the last two octets of the RMI. The first two octets are always 169.254. For
example, if the IP address of the RMI is 209.165.200.225, the IP address of the redundancy port is 169.254.200.225.
The redundancy ports can connect over an L2 path if required. The redundancy port round-trip time must be less than
80 milliseconds if the keepalive timer is left as the default 100 milliseconds, or 80 percent of the keepalive timer.
The keepalive timer range is 100 milliseconds to 400 milliseconds. The failure detection time is calculated as follows:
If the keepalive timer is set to 100 milliseconds, as follows: 3 * 100 = 300 + 60 = 360 + jitter (12 milliseconds) = ~400
milliseconds. Also, ensure that the bandwidth between redundancy ports is 60 Mbps or higher.
NOTE: Ensure that the maximum transmission unit (MTU) is 1500 bytes or higher.
8: WIRELESS BRIDGING (MESH): 10% WEIGHTING ON THE EXAM
MESH NETWORKS:
Within a Mesh Network, AP’s operate in either one of two ways.


Root AP (RAP) (Connects to the wired network)
Mesh AP (MAP) (Is part of the wireless network backhaul)
NOTE: All AP’s are configured by default as Mesh AP’s from Cisco. To use an AP as a Root AP, you must reconfigure the
Mesh AP to a Root AP. Also in all mesh networks, ensure that there is at least one Root AP.
RAPs have a wired connection to the local wired network and a logical connection to their WLC via a CAPWAP tunnel,
whilst the MAPs have wireless connections to other MAP’s and again only a logical one to their WLC. MAP’s
communicate among themselves and back to the RAP using wireless connections over the 802.11a/n radio backhaul.
MAPs use the Cisco Adaptive Wireless Path Protocol (AWPP) to determine the best path through the other Mesh AP to
the WLC. Bridge Mode AP’s (Mesh AP’s) support CleanAir in mesh backhaul at 5GHz frequency and provide only
interference device report (IDR) and Air Quality Index (AQI) reports.
NOTE: The RAP or MAP do not generate (BPDU) itself. However, the RAP or MAP forwards the BPDU to upstream devices
such as if a switch is connected. if the RAP or MAP received a BPDU from its connected wired or wireless interface it will
forward it across the network.
Wireless Mesh networks are designed to carry two different types of traffic. They are the Wireless Client Traffic & the
MAP Ethernet Port Traffic such as CAPWAP etc. Wireless client traffic terminates at the WLC via the CAPWAP tunnel,
and the Ethernet traffic terminates on the Ethernet ports of the Mesh AP’s.
The main purpose of a Mesh network is to extend network connectivity when normal ethernet or other means of
communication infrastructure cannot be accommodated for. These are usually outdoor deployments.
AP AUTHORIZATION: To insure a secure network, registeration access to the WLC for mesh AP’s to join is managed by
the following two authentication methods:

MAC Authentication: Mesh AP’s are added to a database that can be referenced to ensure they are provided
access to a given WLC and mesh network.

External RADIUS Authentication: Mesh AP’s can be externally authorized using a RADIUS server such as Cisco ACS
(4.1 and later) that supports the client authentication type of Extensible Authentication Protocol-FAST (EAP-FAST)
with certificates.
NOTE: For 1500 series outdoor mesh APs, specify its BVI MAC address of the mesh AP into the WLC as a MAC filter. For
indoor mesh AP’s, enter its Ethernet MAC
INDOOR MESH:
A indoor mesh network features two-radios for indoor deployments. One radio can be used for local (client) access and
the other radio can be configured for wireless backhaul.
The backhaul is supported only on the 5-GHz radio. If Universal Backhaul Access is enabled, the 5-GHz radio can be used
for local (client) access as well as a the network backhaul.
Enterprise 11ac mesh supports both P2P (Point-to-Point), P2MP (Point-to-Multipoint) mesh types of architectures. It
supports three spatial streams and 80MHz wide channels for a maximum data rate of 1.3 Gbps which is three times the
maximum data rate of today's IEEE 802.11n.
You can order indoor AP’s set at bridge mode, so that these AP’s can be used deployed quickly. Alternatively, if you
order AP’s in a local mode (non-mesh), then you have to connect these AP’s to the WLC and change the AP mode to the
bridge mode (mesh).
This can become cumbersome particularly if the number of the AP’s is large. Cisco indoor Mesh AP’s are equipped with
the following two simultaneously operating radio’s:
•
•
2.4-GHz radio used for client access
5-GHz radio used for data backhaul and client access if Universal Backhaul Access is enabled
The 5-GHz radio supports the 5.15 GHz, 5.25 GHz, 5.47 GHz, and 5.8 GHz bands.
NOTE: Both MAP and RAP, can provide WLAN client access, however in most cases because of the RAPs location it is not
well suited for providing client access.
OUTDOOR MESH:
Outdoor mesh AP’s comprise of the Cisco Aironet 1500 series units. The 1500 serie AP’s are configured by either by the
GUI or CLI and also Cisco Prime Infrastructure.
The communication between outdoor mesh AP’s (MAPs & RAPs) is over the 802.11a/n/ac radio backhaul. Client traffic is
generally transmitted over the 802.11b/g/n radio (802.11a/n/ac can also be configured to accept client traffic as noted
above).
The 1500 series AP’s come in two different physical configurations:
•
Cable: This configuration can be mounted to a cable strand and supports power-over-cable (POC).
•
Non-cable: This configuration supports multiple antennas. It can be mounted to a pole or building wall and
supports several power options.
Uplinks support includes (1000BASE-T) and a (SFP) slots that can be plugged for a fibre or cable modem interface. Both
single mode and multi-mode SFPs up to 1000BASE-BX are supported.
The Mesh AP’s, can be configured to operate in the following alternative modes:
•
Monitor Mode: In this mode, the AP radios are in the receive state. The AP scans all the channels every 12 seconds
for rogue client beacons, noise floor measurements, interference, IDS events, and CleanAir intruders.
•
Rogue Detector Mode: In this mode, the AP radio is turned off, and the AP listens only to the wired traffic. The
controller passes the APs that are configured as rogue detectors as well as lists of suspected rogue clients and AP
MAC addresses. The rogue detector listens for ARP packets and can be connected to all broadcast domains through
a trunk link.
•
Sniffer Mode: In this mode, the AP captures and forwards all packets on a channel to a remote device that decodes
the packets with packet analyser software such as Wireshark.
•
Bridge Mode: In this mode, the AP is configured to build a wireless mesh network where wired network cabling is
not available.
•
Flex+Bridge Mode: In this mode, both Flexconnect & Bridge mode configuration options are available on the AP.
ADAPTIVE WIRELESS PATH PROTOCOL (AWPP):
The Adaptive Wireless Path Protocol (AWPP) is a routing protocol designed specifically for wireless mesh networking
deployments. AWPP takes advantage of CAPWAP, where client traffic is tunnelled to the WLC and is therefore hidden
from the AWPP process.
Also, the advance radio management features in the CleanAir / RRM solution are available to the wireless mesh network
and do not have to be built into AWPP. AWPP enables a remote Mesh AP to dynamically find the best path back to a
RAP for each MAP that is part of the RAP's bridge group name (BGN). Unlike traditional routing protocols, AWPP takes
RF details into account.
To optimize the route, a MAP actively queries its neighbour MAP’s over its 5GHz radio. During the query, the MAP learns
all of the available neighbours AP’s back to the RAP, and it determines which neighbour offers the best path and then
synchronizes with that neighbour. The path decisions of AWPP are based on the link quality and the number of hops.
The AWPP protocol automatically determines the best path back to the WLC by calculating the cost of each path in
terms of the Signal Strength and number of Hops. After the path is established, AWPP continuously monitors conditions
and changes routes to reflect changes in conditions. AWPP also performs a smoothing function (averaging) to the signal
condition information to ensure that the ephemeral nature of RF environments does not impact network stability i.e to
stop route flapping.
AWPP TRAFFIC FLOW:
The key to the wireless mesh data flow is the address fields of the 802.11 frames being sent between Mesh AP’s. An
802.11 data frame can use up to four address fields: receiver, transmitter, destination, and source. The standard frame
from a WLAN client to an AP uses only three of these address fields because the transmitter address and the source
address are the same.
However, in a Mesh network, all four address fields are used because the source of the frame might not be the
transmitter of the frame, because the frame might have been generated by a device behind the transmitter.
EASE CALCULATION:
Ease is calculated using the SNR and Hop values of each neighbour, and applying a multiplier based on various SNR
thresholds. The purpose of this multiplier is to apply a spreading function to the SNRs that reflects the various link
qualities.
Above shows the parent path selection where MAP2 prefers the path through MAP1 instead of directly through its RAP
because the adjusted ease value (436906) though this path is greater than the ease value (262144) of the direct path
from MAP2 to the RAP. The higher ease value is the prefered route.
PARENT SELECTION:
The relationship among Mesh AP’s can be either a Parent, Child, or a Neighbour. Below is a description of each of these
relationships and their meanings:
•
Parent AP: These AP’s offer the best route back to the RAP based on its ease values. A parent can be either the RAP
itself or another MAP within the Mesh Network.
NOTE: Ease is calculated using the SNR and link hop value of each neighbour. Given multiple choices, generally an
AP with a higher ease value is selected.
•
Child AP: These AP’s selects the parent AP as its best route back to the RAP.
•
Neighbour AP: These AP’s are within RF range of other AP’s but are not selected as a Parent or a Child because its
ease values are lower than that of the currnet Parent.
The AWPP routing protocol follows the below process in selecting Parents for a RAP or MAP with a radio backhaul:
•
A list of channels with neighbours is generated by passively scanning in the scan state, which is a subset of all
backhaul channels.
•
The channels with neighbours are sought by actively scanning in the seek state and the backhaul channel is
changed to the channel with the best neighbour.
•
The Parent is set to the best neighbour and the parent-child handshake is completed in the seek state.
Parent AP maintenance and optimization occurs in the maintain state. This algorithm is run at start-up and whenever a
Parent AP is lost / changed and no other potential Parent AP’s exists and is usually followed by CAPWAP tunnel loss and
WLC rediscovery. All neighbour protocol frames will carry the channel information.
Parent maintenance occurs by the Child AP sending a directed NEIGHBOR_REQUEST to the Parent AP. The Parent AP
will then respond with a NEIGHBOR_RESPONSE. Parent AP optimization and refresh occurs by the Child AP sending a
NEIGHBOR_REQUEST broadcast on the same channel on which its Parent resides, and by evaluating all responses from
neighbouring nodes on its current channel.
NOTE: AWPP uses EASE to determine the best path. EASE can be considered the opposite of cost, and the preferred path
is the path with the higher EASE value.
A Parent Mesh AP is calculated by using the adjusted EASE value, which is the EASE of each neighbour divided by the
number of Hops to the RAP:
Adjusted Ease = min (ease at each hop) Hop count.
SNR SMOOTHING:
One of the challenges in Wireless Mesh routing is the short timeframe of how RF conditions will change, which must be
considered when analysing an optimal path and deciding when a change in path is required.
The SNR on a given RF link between Mesh AP’s can change substantially from moment to moment and changing route
paths based on these fluctuations results in an unstable network, with severely degraded performance. To effectively
capture the underlying SNR but remove moment-to-moment fluctuations, a smoothing function (averaging) is applied
that provides tolerance.
In evaluating potential Neighbours AP’s against the current Parent, the current Parent AP is given 20 percent of bonusease on top of its calculated EASe when comparied to other potential Parent AP’s, to reduce the ping-pong effect
between Parent AP’s. A potential Parent AP must be significantly better for a Child AP to make a routing path change.
Parent AP switching is transparent to CAPWAP and other higher-layer functions.
LOOP PREVENTION:
To ensure that routing loops are not created, AWPP discards any route that contains its own MAC address in the table.
That is, routing information apart from hop information contains the MAC address of each hop to the RAP; therefore, a
Mesh AP can easily detect and discard routes that loop.
WIRELESS BACKHAUL:
Traffic on a wireless backhaul can be from either wired devices that are being bridged by the wireless mesh or CAPWAP
traffic from other Mesh AP’s which is their client traffic. This traffic is always AES encrypted when it crosses a wireless
backhaul mesh link.
AES encryption is established as part of the Mesh AP neighbour relationship with other Mesh APs. The encryption keys
used between Mesh APs are derived during the EAP authentication process. Only 5GHz backhaul are possible on all
Mesh APs except 1522 in which either 2.4 or 5GHz radio can be configured as a backhaul radio.
POINT-TO-MULTIPOINT WIRELESS BRIDGING:
A deployment with one RAP and two MAPs, can be configured as either a wireless backhaul only or both backhaul and
also servicing wireless clients (Ethernet Bridging). Client access can be provided if Ethernet Bridging is enabled, although
if bridging between buildings, MAP coverage from a high rooftop might not be suitable for client access.
Ethernet port on the MAPs are disabled by default, however they can be enabled only by configuring Ethernet Bridging
on the Root and the respective MAPs along the path. To enable Ethernet bridging using the controller GUI, choose
Wireless > All APs > Details from the AP page, click the Mesh tab, and then check the Ethernet Bridging check box.
Ensure that you enable Ethernet bridging for every Parent AP taking the path from the Mesh AP in question to the WLC.
For example, if you enable Ethernet bridging on MAP2 in Hop 2, then you must also enable Ethernet bridging on MAP1
(Parent MAP), and on the RAP connecting to the WLC (The entire path).
WIRELESS BACKHAUL DATA RATES:
The backhaul interface by default is 802.11a or 802.11a/n. Dynamic Rate Adaptation (DRA) introduces a process to
estimate optimal transmission rate for packet transmissions. It is important to select rates correctly.
If the rate is too high, packet transmissions fail resulting in communication failure. If the rate is too low, the available
channel bandwidth is not used, resulting in inferior performance, and the potential for catastrophic network congestion
and collapse.
Data rates also affect the RF coverage and network performance. Lower data rates, for example 6 Mbps, can extend
farther from the AP than can higher data rates, for example 300 Mbps. As a result, the data rate affects cell coverage
and consequently the number of APs required.
Different data rates are achieved by sending a more redundant signal on the wireless link, allowing data to be easily
recovered from noise. The number of symbols sent out for a packet at the 1-Mbps data rate is higher than the number
of symbols used for the same packet at 11 Mbps. Therefore, sending data at the lower bit rates takes more time than
sending the equivalent data at a higher bit rate, resulting in reduced throughput and performance.
A lower bit rate might allow a greater distance between MAPs, but there are likely to be gaps in the WLAN client
coverage, and the capacity of the backhaul network is reduced. An increased bit rate for the backhaul network either
requires more MAPs or results in a reduced SNR between MAPs, limiting mesh reliability and interconnection.
CELL PLANNING & DISTANCE:
The RAP-to-MAP ratio is the starting point. For general planning purposes, the current ratio is 20 MAPs per RAP.
Cisco recommends the following values for cell planning and distance in non-voice networks:
•
RAP-to-MAP Ratio: Recommended maximum ratio is 20 MAPs per RAP.
•
AP-to-AP distance: A spacing of no more than of 2000 feet (609.6 meters) between each Mesh AP is
recommended. When you extend the mesh network on the backhaul (no client access), use a cell radius of 1000
feet (304.8 meters).
•
Hop Count: Three to four hops. One square mile in feet (52802), is nine cells and you can cover one square mile
with approximately three or four hops. For data, the maximum is 4 hops. No more than 2 hops are recommended
for a voice network.
•
2.4 GHz, the local access cell size radius is 600 feet (182.88 meters). One cell size is around 1.310 x 106, so there are
25 cells per square mile.
MULTIPLE RAPS:
If multiple RAPs are being deployed to provide hardware diversity, the additional RAP(s) should be deployed on the
same channel as the primary RAP to minimize the convergence time in a scenario where the mesh transfers from one
RAP to another. When you plan RAP hardware diversity, consider the rule of 32 MAPs per RAP limitation.
NOTE: If additional RAPs are deployed to primarily provide additional capacity, then the additional RAPs should be
deployed on a different channel than its neighbouring RAP to minimize the interference on the backhaul channels.
FAST CONVERGENCE MODES:
With Cisco WLC, you can configure mesh convergence methods per mesh AP (MAP) or for all Mesh APs. This enables
you to choose the convergence methods based on deployment without affecting the existing convergence mechanism.
The default setting is the existing convergence mechanism.
Mesh Convergence
Parent Lost Detection / Keep Alive Timers
Channel Scan / Seek
DHCP / CAPWAP Information
Standard
21 / 3 Seconds
Scan / Seek all 5-GHz channels
Renew/Restart CAPWAP
Fast
7 / 3 Seconds
Scan / Seek only present channels
Maintain DHCP and CAPWAP
Very Fast
4 / 1.5 Seconds
Scan / Seek only present channels
Maintain DHCP and CAPWAP
PASSIVE CLIENT FEATURE:
When a Cisco workgroup bridge (WGB) is used, the WGB informs the infrastructure AP’s of all the wired clients that it is
associated with. When non-Cisco WGBs are used, the controller has no information about the IP address of the clients
on the wired segment behind the WGB.
Without this information, the controller drops the following types of message requests:
•
ARP REQ from the distribution system for the WGB client
•
ARP RPLY from the WGB client
•
DHCP REQ from the WGB client
•
DHCP RPLY for the WGB client
The following are some guidelines for non-Cisco workgroup bridges:
•
The controller can accommodate non-Cisco WGBs so that the controller can forward ARP, DHCP, and data traffic to
and from the wired clients behind workgroup bridges by enabling the passive client feature.
To configure your controller to work with non-Cisco WGBs, you must enable the passive client feature under the SSID so
that all traffic from the wired clients is routed through the WGB to the infrastrcture AP.
•
When a WGB wired client leaves a multicast group, the downstream multicast traffic to other WGB wired clients is
interrupted briefly.
•
If you have clients that use PC virtualization software such as VMware, you must enable this feature.
•
You must enable the passive client functionality for all non-Cisco workgroup bridges.
•
You might need to use the following commands to configure DHCP on clients:
1. Disable DHCP proxy by using the config dhcp proxy disable command.
2. Enable DHCP boot broadcast by using the config dhcp proxy disable bootp-broadcast enable command.
RESTRICTIONS FOR NON-CISCO WORK GROUP BRIDGES:
•
Only Layer 2 roaming is supported for WGB devices.
•
Layer 3 Security (web authentication) is not support for WGB clients.
•
Visibility of wired hosts behind a WGB on a controller is not supported because the non-Cisco WGB device
performs MAC hiding. Cisco WGB supports IAPP.
•
ARP poisoning detection does not work on a WLAN when the flag is enabled.
•
VLAN select is not supported for WGB clients.
•
Some third-party WGBs need to operate in non-DHCP relay mode. If problems occur with the DHCP assignment
on devices behind the non-Cisco WGB, use the config dhcp proxy disable and config dhcp proxy disable bootpbroadcast disable commands.
The default state is DHCPproxy enabled. The best combination depends on the third-party characteristics and
configuration.
NOTE: A WGB can support a maximum of 20 clients.
NOTE: Access points configured in WGB mode do not respond to broadcast Radio Measurement Requests that are sent
as a result of the Cisco Compatible Extensions Location Measurement parameter being enabled. Therefore, Cisco
Compatible Extensions Location Measurement cannot be used as a mechanism with which to trigger consistent periodic
probing in work group bridges.