Chapter 14

Advanced Location Services Implementation

This chapter covers the following topics:

CMX and DNA Spaces Services and Licenses: This section provides an overview of the main services available on CMX and DNA Spaces. This section also discusses which services are core to the network administrator and which are the focus of specialized engineers.

Implementing Analytics: This section discusses how to use the analytics services available on both CMX and DNA Spaces and also contrasts the implementation differences between both platforms.

Implementing Guest Portals: This section shows how to configure location-specific portals for visitors and guests on CMX and DNA Spaces. The section also details the WLC guest WLAN configuration for AireOS and C9800.

Implementing WIPS on MSE: This section details how to configure MSE 8.0 for an adaptive wireless intrusion prevention system.

Ensuring Location Operational Efficiency: This section shows how to configure MSE high availability. It also details the steps to take to verify and optimize location accuracy.

This chapter covers the following ENWLSI exam topics:

5.1 Implement CMX Components
- 5.1.a Detect and Locate
- 5.1.b Analytics
- 5.1.c Presence Services
5.2 Implement location-aware guest services using custom portal and Facebook Wi-Fi
5.3 Troubleshoot location accuracy using Cisco Hyperlocation
5.4 Troubleshoot CMX high availability
5.5 Implement WIPS using MSE

Location services are not limited to performing the location of individual devices. Most businesses need to manage resources based on the number of users likely to use these resources. This requirement means detecting mobile network users, counting them, understanding how they roam, identifying the areas where density peaks appear, measuring how long they stay in each zone, how much bandwidth they consume, and so on.

Therefore, an efficient location solution should do more than just locate devices. Based on this location information, the solution should offer various metrics about Wi-Fi users, along with functions to ease the task of managing Wi-Fi users.

This chapter introduces advanced location services, which are those services that leverage location information in order to provide additional functions. You will learn not only which additional functions, based on location, are available in Cisco CMX and DNA Spaces but also which ones are “must-knows” and which ones are beyond the expected scope of a networking professional and belong to the domain of specialized engineers. Among these services, you will learn how to manage analytics to better understand users and network patterns. You will also learn how to implement location-specific guest portals. This ability is particularly important in public spaces, where providing environmental information is expected for most Wi-Fi guest users. You will then learn how to implement wireless intrusion prevention by using location information to detect and mitigate Wi-Fi-based attacks. Location is the fundamental brick behind all these services. Therefore, in the last section of this chapter, you will learn how to ensure that location continues to be performed at the level of accuracy needed by your deployment.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 14-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix D, “Answers to the ‘Do I Know This Already?’ Quizzes and Review Questions.”

Table 14-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section	Questions
CMX and DNA Spaces Services and Licenses	1
Implementing Analytics	2–3
Implementing Guest Portals	4
Implementing WIPS on MSE	5
Ensuring Location Operational Efficiency	6

1. Which of the following represents the MSE trial license allowance?
1. All services, 120 days for 100 APs
2. Location only, for 10 APs and 30 days
3. One guest portal and one AP, 60 days
4. Presence only, and all guest portals in read-only mode
2. Which license level is required on DNA Spaces to activate Location Analytics functions?
1. Advance license
2. Act license
3. Analytics+ license
4. Insight license
3. What is a “zone” in CMX Analytics?
1. The coverage area of a single AP (that is, the AP cell)
2. An area where location can be computed with good accuracy
3. An area where devices are expected to be mobile (that is, a transition area)
4. An area with a label, with no specific RF meaning
4. How does a C9800 redirect ACL to ensure that traffic targeting the MSE IP address is redirected to the MSE?
1. With a specific permit instruction
2. With a specific deny instruction
3. With a final permit any wrapper
4. With a final (implicit) deny any wrapper
5. Can you perform real-time WIPS with an AP in Monitor (no submode) mode?
1. No, intrusion prevention is only active if the AP is set to WIPS mode, with Monitor submode.
2. No, intrusion prevention requires the Local or Monitor mode with WIPS submode.
3. Yes, intrusion prevention works seamlessly with all AP modes and submodes.
4. Yes, you can if the AP is assigned to a WIPS zone in CMX.
6. To which MSE port does a WLC send AoA messages?
1. The WLC does not send AoA messages; APs send them directly to MSE.
2. TCP 16113
3. UDP 2003
4. The WLC does not send AoA messages; MSE pulls them from the WLC using NMSP.

Foundation Topics

CMX and DNA Spaces Services and Licenses

Chapter 13, “Location Services Deployment,” primarily focused on location services. However, both CMX and DNA Spaces integrate multiple other components that a networking professional should be familiar with. This section does not describe all possible services, as some of them are considered “advanced” and the domain of specialized professionals. Additionally, new services appear all the time that you may see in the interfaces and not described here. Make sure to keep up-to-date with the exam blueprint to verify which services you are expected to master.

CMX Services and Licenses

CMX integrates several services that you can activate either independently or as a superset of one another. Some services are activated at installation time and come with an evaluation license. Other services require an activation license. Licenses are purchased and downloaded in an .lic file. To install a license file, navigate to Manage > Licenses and import the .lic file. You can install two types of licenses:

A CMX Base license, which includes the CMX Connect, CMX Locate and Detect, and High Availability capabilities.
A CMX Advanced license, which includes all CMX Base license capabilities, along with the CMX Analytics and DNA Spaces Connector capabilities.

The Locate and Detect capability is the function referred to as “location” in much of the literature and in Chapter 13. This service uses the data provided by Cisco WLCs and APs (RSSI and AoA) to calculate the location of wireless devices that are detected by the access points. The service is activated by default when you install CMX with a 120-day trial period. This temporary license is valid for all CMX services and 100 APs.

The Analytics service provides additional tools for analyzing Wi-Fi device locations. This service is called Analytics when leveraging the output of the Locate and Detect service, and Presence Analytics when using only nearest AP or associated AP location. When you install CMX, you need to specify if you want to enable location or presence (you cannot enable both). In small indoor deployments and most outdoor deployments, presence is sufficient. However, you need to enable location to use AoA or FastLocate and to obtain an accurate individual device location.

The Connect service provides a location-specific guest web portal interface to onboard visitors with Facebook or OAuth-based credentials. The service can be enabled with location or presence.

DNA Spaces Services and Licenses

DNA Spaces (Cloud) also implements a large set of services, some of which complement services available with on-premises CMX. Services are activated with licenses enabled directly within the DNA Spaces cloud interface. Two license types are available, each for 3-, 5-, or 7-year durations:

See: The See license offers business metrics, Wi-Fi metrics, real-time metrics, location computation (RSSI trilateration), and location hierarchy visualization.
Act: The Act license offers all the features available in the See license and also the Captive portal function (what MSE calls “Connect”) with profile rules and Engage features (to send notifications to Wi-Fi users based on rules and the user location), an API to expose location to third-party applications (with Webhook), a partner stream feature (to stream data in and out of DNA Spaces), operational insights, and Hyperlocation if you also have an on-premises CMX (where this Hyperlocation is first computed).

The feature set partially overlaps with the CMX features described previously. The metric features provide the equivalent of what CMX describes as Analytics. Business metrics allow you to measure the impact of a particular marketing campaign on your Wi-Fi traffic. Real-time traffic shows the clients in real time in each location, and Wi-Fi metrics show the number of clients per location and SSID.

As a networking professional, you may be asked to help business owners determine which feature requires which solution combination and with which type of license. Table 14-2 can help you answer most of these questions. Note that the DNA Spaces solution is very fluid. Always verify on Cisco.com the latest license and feature combination.

Table 14-2 DNA Spaces and CMX Feature Combination

Feature	License	X/Y Location or Presence	CMX On-Prem. Required
Cisco DNA Center integration	See	X/Y	Yes
Cisco Prime Infrastructure integration	See	X/Y	Yes
Business insight	See	Presence	No
Hyperlocation	Act	X/Y	Yes
Captive portal	Act	Presence or X/Y	No
Engagement	Act	Presence or X/Y	No
Location personas	Act	Presence or X/Y	No
Operational insight	Act	X/Y	No
BLE Manager	Act	X/Y	Yes
Location Analytics	Act	X/Y	Yes
Partner Stream	Act	X/Y	Yes
Third party via API/Webhook	Act	X/Y	No

Implementing Analytics

Analytics is a critical component of the administrator toolbelt. As soon as location, or even presence, is computed, businesses need to know the user density so as to deploy network resources (or staff) accordingly. Analytics can be implemented on either CMX or DNA Spaces. There are basic differences between these platforms that you need to know and advanced functions that are not critical to the nonspecialist.

Implementing CMX Analytics

The CMX Analytics service is often confused with the Detect and Locate service, because Analytics relies on location information. Make sure to understand their differences. Detect and Locate provides the computed location for each detected device at individual moments in time. This information is stored in CMX database. The Analytics service then provides a set of data analytic tools packaged for analyzing Wi-Fi device locations. In other words, the service uses the location information (that is, it needs Detect and Locate to provide valid information) and functions as a data visualization engine that helps organizations use their network as a data source for business analysis to understand behavior patterns and trends, which can help them make decisions on how to improve visitor experience and boost customer service. Depending on the granularity of the information you need, you can obtain location through the CMX Presence function or through the full Location function. With Presence, devices’ locations are approximated to the nearest AP (unassociated devices) or associated AP (associated devices). With Location, depending on which features you enabled, devices’ locations are determined using RSSI trilateration and AoA, using the signal coming from broadcast messages or unicast messages (when FastLocate is activated).

Defining Zones

Whereas Detect and Locate typically starts from the idea of locating individual devices, Analytics functions at the zone level and for a specific time period. The zone can be any hierarchical block, campus, building, floor, or zone on a floor. You can access your zones from Manage > Location. In the left pane of the window that is displayed, you can click Campus, Building, Floor, or Zone, depending on the area you want to view. Click the curved arrow at the top-right corner of each item box to view details pertaining to that item. The curved arrow at the top-right corner of a floor box is called the Go to map view arrow. This arrow is available on the box of items at any level. For example, for a building, this opens the first floor. For a campus, this opens the first floor of the first building. You can then switch to other buildings and floors in that campus. When you click the top-right corner curved arrow and the map opens, you are in what CMX calls the Zone Editor. From there, in the right part of the screen, icons appear that allow you to create (a pen icon), delete (a trash can icon), or edit (a pen in a square icon) several objects:

Perimeters: A perimeter defines the area where location is performed. With location inaccuracies, your clients may appear a few meters from their real position. At the edge of the coverage area, this may mean that some devices appear to be outside of the building, floating in the air. A common practice is to define the perimeter as the edge of floor area, preventing the devices from showing as being outside of that perimeter line (they will be shown inside, close to the perimeter line), thus avoiding that location inaccuracies display the devices in a location where they cannot be.
Inclusion areas: An inclusion area defines a zone where devices can appear. Devices for which location is detected outside of the inclusion area will be snapped on the boundary. You can define only one inclusion region per floor. When there is no inclusion region defined in the floor maps, Cisco CMX creates a default inclusion region that is the same as the floor dimension.
Exclusion areas: An exclusion area defines a zone where a device cannot be present. There can be multiple exclusion regions on a floor. Depending on your floor layout, you can use the inclusion areas, exclusion areas, or both to avoid displaying devices where they cannot be present. For example, in a factory where workers are limited to a small set of walking paths between large machines, you can define an associated inclusion area. If only a few locations are inaccessible, use exclusion areas.
Zones: A zone is an area with a label. The zone does not need to have particular significance from an RF standpoint, and it commonly represents an area that makes sense for the network administrator (for example, “entrance and lobby” or “store XYZ”).

When you create an object, you click at the corners of the matching polygon until the object covers the area you need. Then, when you edit the object, you can click any vertex to move it. You can also double-click any point of a line to create a new vertex at this position (then move it if needed). You can also click inside the object (the mouse arrow changes to a hand) to move it.

Configuring Analytics Widgets

Analytics provides insights about clients in your different zones. For each of them, and for a given time period, the Analytics service allows for the visualization of six different types of location-related elements:

Device count: For the target zone, this element displays the number of detected clients (associated or not). This widget is useful to understand the user density. As the function is correlated with a particular time period, you can also see a summary of how this count compares to the previous period, including the user count trend (up or down, compared to the previous period), how many users are new, and how many are repeat visitors.
Dwell time: For the target zone, this element displays the average duration for which clients (associated or not) were detected. This widget is useful to distinguish zones where clients are just passing by from zones where clients stay for a longer time. The widget distinguishes new from repeat visitors, as their behavior may be different. For example, repeat visitors may go directly to a particular location, while new visitors may spend more time exploring transition areas. The function also displays the trend and comparison with previous periods.
Dwell time breakdown: For the target zone, this element displays a more detailed view of the dwell time by durations. You can see the percentage of devices that were detected in the target zone for less than 5 minutes, between 5 and 20 minutes, 20 and 60 minutes, 60 to 120 minutes, or more than 120 minutes. Here again, you can see trends and comparisons with previous periods.
Associated user or probing only: For the previous widgets, you can filter the view to only display devices that effectively associated to the network or that only probed (and never associated). In some versions of CMX, this function is also called Wi-Fi adoption, representing the number of clients that decided to adopt and join your Wi-Fi network. Here again, you can compare between periods. You can also visualize the visits or the devices. With the visit view, a device that is detected, then leaves the area (or stops being detected for a configurable timeout value), and then is detected again will be counted as visiting the zone twice. With the device view, you will see a count of unique MAC addresses, regardless of how many times they entered or left the zone.
Path: This element analyzes the paths taken by visitors (or client devices) before and after visiting a focus location as well as provides a graphical representation of the paths. The green (left) side represents where a device is coming from (for example, immediately before entering the focus zone). The blue (right) side represents where a device goes (for example, immediately after exiting the focus zone). Hovering your cursor over the focus reveals a breakdown based on percentage of paths that either started or ended in the focus zone and the percentage of paths that either arrived or departed from the focus zone. Hovering your cursor over a green section shows the number of paths that entered the focus zone originated in this zone. Hovering your cursor over a blue section shows the number of paths that originated in the focus zone ended in this zone.
Correlation: This element provides a detailed summary of correlation of client devices between two locations. Correlation data can be used to determine the relation between two zones. Low correlation between zones indicates lack of access between the two zones. For example, you can expect a high correlation between the food court and the cinema in a shopping mall. As the widget is based on the idea of comparison, you can select the zones to compare (they can be what CMX calls “zones,” but they can also be entire floors or buildings) and then display the output as a graph or as a table.

Figure 14-1 displays some of the Analytics widgets. As a networking professional, you need to be familiar with the different widget types.

Images — **Figure 14-1** *CMX Analytics Widgets*

The widgets are accessible in the CMX dashboard, but they can also be generated as reports. The report can focus on the data of an existing widget, a specific time slice or a subset of SSIDs, or can be completely customized. To generate such custom report from the Analytics dashboard, in the left panel of the dashboard, click the Add icon. The Create New Report window is displayed. Choose Customized from the Report Type widgets row in the right pane and then choose the locations that you want to analyze from the Focus Area Filter drop-down list. The location types are Building, Campus, Floor, and Zone. Choose the date and time range you want to run the report for from the Date & Time filters drop-down list. You can click the dot at the bottom of the Add Widget area to scroll to the next set of options. You can select multiple widgets to combine in one overall widget: in the Add Widget area, click the Add+ icon to include any of the existing widgets in the report. You can select multiple widgets to combine into one overall widget. You can also set a threshold for dwell time. This is the amount of time spent by a client device (visitor) at a given location, which is set by selecting the minimum and maximum times from the drop-down options in the Advanced Widget Filters area. Once your selection is made, click Done to create the widget. Repeat as many times as you need to add the widget. At the end, click the report title to name your report and click Save to validate.

These reports are very useful to watch the evolution of your network over time. They rely on an efficient initial setup, where zones are designed logically and location is provided with an accuracy that matches the zones’ definition. If you deployed Presence instead of Location, you will also see the visitor count, dwell time, and dwell time distribution, with the same granularity as with Location about repeat versus first-time visitors. However, the location will be limited to proximity to a site where detecting APs are present. You cannot create subzones.

Implementing DNA Spaces Analytics

CMX supposes that you install a server on premises. This is especially useful if you need to track, in near real time, the location of individual MAC addresses. If you only need analytics, then the WLC can aggregate station counts and locations and then send its observations in batches. In this case, your need for bandwidth decreases, as you do not need an update for each MAC and each movement anymore. DNA Spaces, in the cloud, can then be a good solution, providing the data you need without the need to manage your own appliance.

Initial Setup

The first element needed to efficiently manage Analytics with DNA Spaces is to set up locations and maps. This function is accessible by clicking the lines icon in the upper-left corner of the DNA Spaces dashboard screen and choosing Setup. From the Setup menu, you can add wireless networks or maps. A new wireless network is an on-premises CMX, a DNA Spaces Connector, or a WLC with direct connection that has been uploaded to DNA Spaces. Refer to Chapter 13 for the connection details. The map service allows you to define the various campuses, buildings, and floors that you want to manage. You can also upload floor plans, position APs, and create zones, as described in Chapter 13.

Once you have maps and wireless networks, from the main dashboard menu, select the Location Hierarchy function, as displayed in Figure 14-2.

From the Location Hierarchy page, you can visualize all your sites with the root account at the top (called DNACDemo in this section). For each site, you can see the number of locations (represented by a geolocation icon), the number of APs (represented by a WiFi AP icon), the number of BLE beacons (represented with the Bluetooth icon), the number of proximity rules (represented by a document icon), and the number of users (represented by a human figure icon), as shown in Figure 14-3. On the left side of each site, a plus sign can be clicked to expand the site. When you hover your mouse to the right side of the root site beyond the User Count, a More Actions icon appears. From this menu, you can rename your root site but also add a new wireless network or create a new group. This way, you can associate wireless networks, maps, and zones to groups, and even group groups together.

Managing DNA Spaces Analytics

Once this setup is complete, the Analytics service is fairly automated. From the main dashboard, by clicking the Location Analytics icon, you can see graphs of the number of visitors and visits, as shown in Figure 14-4, and also dwell time and dwell time breakdown for your network, as displayed in Figure 14-5.

You can choose to visualize the statistics for all SSIDs and networks, or you can filter by locations (groups, then buildings, floors, or zones), dates, and SSIDs.

Similarly, from the main dashboard, you can click the Behavior Metrics widget and obtain metric data complementary to those of location metrics. In this page, you can see not only the visits’ duration and frequency, as shown in Figure 14-6, but also the duration of these visits and a distribution of which visitors were detected at more than one location, as shown in Figure 14-7.

At the bottom of the page, you can also see a visit distribution by hour of day and day of the week, as shown in Figure 14-8.

For all the elements on this page, you can use the top filter function to focus on a specific location, group of locations (assembled together under the same tag), or time period.

The features listed so far in this section for DNA Spaces are accessible with the See license. When you implement the Act license, you also have access to the Operational Insight function. When you click this widget in the DNA Spaces dashboard, you can monitor specific assets (MAC addresses, BLE, or RFID tags) and get notifications when these assets enter or leave a zone. Just like the equivalent function in CMX, this advanced function is beyond the scope of this book. You can find configuration details here:

https://www.cisco.com/c/en/us/td/docs/wireless/cisco-dna-spaces/operationalinsights/b_operationalinsights/b_operationalinsights_chapter_01.html

Implementing Guest Portals

The other major tool in the administrator toolbelt is the ability to create location-specific portals for guests and visitors connecting to the local Wi-Fi. This function heavily relies on location capabilities and can be implemented both on CMX and DNA Spaces.

Implementing CMX Connect Service

The CMX Connect service is a customizable and location-aware guest captive portal service. You access it by clicking Connect in the upper menu of the CMX main window.

Note

Depending on your version of CMX, the menu may also be called Connect & Engage.

The CMX Admin user role can, of course, be used to create anything. This role has access to the Connect dashboard and can configure portals (called Experiences), policies, and the Connect settings, along with all the other CMX services. However, you may also want to create a Connect role, dedicated to Connect management. Such a role is created from Manage > Users. The Connect role can also access the Connect dashboard, create Experiences and policies, access the Connect settings, but cannot access other services on CMX. You can also create a ConnectExperience user, who can create portals (Experiences), can see (but not change or create) policies and the Connect settings, but cannot access the dashboard and, of course, cannot manage other CMX services.

Connect Service Overview

The Connect main page shows a dashboard and a location filter, as you can see in Figure 14-9.

The dashboard contains a summary report page with the user count per portal and zone for the present day. It also contains a historical page, where you can see New and Repeat Visitors (new visitors are the people seen for the first time, and repeat visitors are those recognized from an earlier visit), Network Usage (the total amount of data uploaded and downloaded by all visitors), a count of pages served versus submitted (pages served is the number of times a portal page was displayed to the visitors’ devices, while pages submitted is the number of times a portal page was submitted by the visitors), SMS sent versus authenticated (that is, the total number of texts sent versus the number of texts used to successfully authenticate visitors), and the languages used (count of visitors authenticated using each language). From the dashboard, you can export this information and also search for visitors by name or MAC address.

The main element for Connect is the portal (Experiences). When connecting to the guest WLAN, the user is redirected to CMX, where the local portal is displayed or where the request is relayed to Facebook or another social media platform. Therefore, in order to provide the correct Experience, you need to configure the following:

Your WLC WLAN for WebAuth and redirect to the correct CMX Experience
Your CMX Experience to define which zone it should apply to and what authentication source it should use

Configuring the WLC for Guest Portal Services

The first step is to configure your WLAN. The process is slightly different depending on whether you will be using your CMX as the web portal or if you want the social media provider (for example, Facebook) to also provide the web interface for your user authentication. If CMX is the web portal, you need to create a preauthentication ACL on your WLC, allowing HTTPS traffic to and from the CMX IP address (in the examples that follow, this is represented as the IPv4 address 10.10.10.124). If your social media provider is also the web portal, you also need to allow HTTPS traffic to and from any source and destination IP address. Setting a permit rule for HTTPS mechanically denies any other traffic. An example of such a rule is displayed in Figure 14-10. In AireOS, this ACL is created from Security > Access Control List > Access Control Lists > New. Click Add New Rule to insert individual lines and follow the wizard to define the direction and protocol.

Once the ACL is configured, in your AireOS WLAN configuration, in Security > Layer 2, set the security to None and click Apply. In the Layer 3 tab, choose Web Policy. For web passthrough, choose Passthrough. Then choose the preauthentication ACL you created in the previous paragraph. Also override the global authentication and web authentication pages by checking the Over-ride GlobalConfig check box. You need to also define the web authentication pages for wireless guest users, from the Web Auth Type drop-down list, by choosing External (Re-direct to external server). This redirects clients to an external server for authentication. The server can either be CMX (in the case of a local portal) or the CMX relay page for Facebook or another social media provider (such as Instagram or Foursquare). In the URL field, enter the corresponding portal on Cisco CMX, either for a CMX-based portal or for CMX redirection to an external social media portal provider (for example, https://<CMX>/fbwifi/forward). An example is show in Figure 14-11. Click Apply to validate.

The method is slightly different in Catalyst 9800, where you first have to create a parameter map from Configuration > Security > Web Auth. Create a new parameter map of type consent, as shown in Figure 14-12.

Once the parameter map is created, click it in the list to edit its settings. Click the Advanced tab and enter the portal URL, along with the MSE IP address, as shown in Figure 14-13.

You also need to create an redirection ACL, from Configuration > Security > ACL. The ACL is of type IPv4 extended (or IPv6 extended). Deny all HTTPS traffic (if you use Social media authentication) and HTTPS traffic to and from MSE (in all cases). Denied traffic will cause redirection to the Redirect URL. Allow all other traffic. An example is shown in Figure 14-14.

AireOS vs. C9800 ACLs

On AireOS, traffic denied by this type of redirection ACL triggers redirection to the redirect URL defined in the WLAN configuration page. Traffic that is not denied (that is, traffic that is permitted) is simply permitted. Therefore, the AireOS ACL in Figure 14-10 allows all HTTPS traffic (as this rule is necessary to allow HTTPS to any social media web page) and also allows all HTTPS traffic to and from CMX. Any other traffic is denied (implicitly), which means that any other traffic (including HTTP) will cause a redirection to the Redirect URL (the CMX login page in our case).

On Catalyst 9800, traffic that is permitted by the redirection ACL causes redirection to the redirect URL. In other words, the ACL defines which traffic you allow to be redirected (while AireOS defines which traffic is allowed to go through). On C9800, traffic that is not permitted by the redirect ACL (that is, traffic that is denied) is simply permitted to go through without redirection. This is why the C9800 redirection ACL looks somewhat like the opposite of the AireOS redirection ACL. What you allow on one platform is what you deny on the other.

Then, navigate to Configuration > Tags & Profiles > WLANs. Click Add to create a new WLAN. In Layer2, set the Layer 2 security mode to None. In Layer3, click Web policy. Set the Web Auth Parameter Map to the parameter map you created in the previous paragraph. Click the Advanced Settings link. Enable the Splash web redirect function and call the preauthentication ACL you created before, as shown in Figure 14-15.

Configuring a Portal on CMX

Once your WLC is configured, you can create Experiences (portals) in CMX from Connect > Library. There, you can see the portals you already created (Portals tab) and create a new Portal by clicking Create New Portal, as shown in Figure 14-16.

Clicking Create New Portal redirects you to the Templates page, where you can choose from among six types of authentication, as shown in Figure 14-17.

Selecting an individual template guides you through a portal creation wizard, where you can name your portal and design the login page based on existing and customizable page elements (background, images, and so on). CMX will generate the matching web pages for laptops, tablets, and phones. Each option has design and customization elements for which you can find detailed configuration instructions in the CMX Connect Configuration Guide at https://www.cisco.com/c/en/us/td/docs/wireless/mse/10-6/cmx_config/b_cg_cmx106/the_cisco_cmx_connect_and_engage_service.html. One key element of your portal is the Opt-Out option, which allows clients to opt out of having their mobile device location history maintained and used by Cisco CMX. When a client opts out, Cisco CMX stops detecting the client’s device MAC address and thus stops storing analytics data for that device. Either the client no longer appears on maps or appears not to be moving (that is, the X,Y location data remains the same). The default is Opt-In. When Opt-Out is configured, the default opt-out period is 180 days (and can be changed as you configure the option in the portal). When the period ends, the Opt-Out option reappears when the client displays your login portal.

Note

Opt-out does not mean that the client MAC address is not retained. The option means that the MAC address location is not tracked beyond portal assignment.

Once the portal is created, you can go back to the Connect Experiences tab, where all your locations are displayed. For each of them, you can select the portal to use, as displayed in Figure 14-18. This part supposes that floors and zones are already created. You can also go to Manage > Locations, navigate to a floor, and click Zones. You can then use the Draw Polygon Zone option to draw a specific zone on that floor, as detailed in a previous section. Then, in Connect, you can assign a specific Experience and Policy Plan to each zone on the floor.

Note

At the top of each column, the “i” icon can be used to display the redirect URL that should be entered in your WLAN Redirect URL field.

Once this configuration completes, any new user joining your guest WLAN will be redirected to CMX, where the user will be located and redirected to the matching portal.

You can also create policies associated to Experiences and locations. The Policy Plans feature gives you the option to provide your client with different bandwidths as the client moves from one location to the next. For example, the bandwidth provided to clients in a hotel room could be higher than the bandwidth provided in a hotel lobby. From Connect > Policy Plans, click New Policy Plan and then provide a name and a bandwidth value (in Kbps).

Implementing DNA Spaces Connect Service

The equivalent of CMX Connect on DNA Spaces is called Captive Portals. The WLC configuration is identical to the CMX configuration. Refer to the previous section for details.

Creating a New Portal from Scratch

When you click the Captive Portals widget on DNA Spaces main dashboard, you access a page where all your existing portals are listed, as shown in Figure 14-19.

To create a new portal from scratch, click Create New. The wizard first asks you to enter a name for the new portal and to select which location the portal should be applied to. You can choose to apply the portal to all locations, or you can select one or more locations. Click Next to continue. The following page allows you to define how users will be authenticated. You can choose to have a password sent to a phone number of their choice. This option is optimal when the device to connect is not a phone (but the user has access to a phone). Alternatively, the system can send a connection link to a phone number. This option is better, if the device to connect is the phone itself, as shown in Figure 14-20. The authentication step can also take the form of a simple email address, a social media account, or no authentication at all.

Regardless of the authentication mode chosen, you can decide if the user agreement should be displayed on the portal home page and if users can be given the choice to opt in (or not) to receive additional messages. Once your authentication choice is made, click Next to continue. The next page, Data Capture, allows you to collect more information from the users. You can ask them to enter their title, mobile number, first and last names, gender, a tag (for example, their role), and also their ZIP code (or CPF code in Brazil). Such additional data capture is optional. Click Next. The last page of the wizard displays the terms and conditions. You can enable or disable the display of these conditions and then edit them as needed. Click Save & Configure Portal to exit this part of the wizard.

A new page opens, shown in Figure 14-21, that allows you to customize your portal page, including different forms for phones, tablets, or laptops, and also different languages. Once your customization is completed, click the back arrow in the upper-left corner of the page to exit the wizard.

Your portal now appears in the list. At any point if you hover over the portal line, you can click the pen icon to edit the portal again, the trash can icon to delete the portal, or the copy icon to duplicate the portal.

Creating a New Portal from a Template

Duplicating is a common task, as many enterprises use variations of a main template based on specific location needs. If you do not want to create a portal manually, the bottom of the Captive Portals page also contains various templates you can use, as shown in Figure 14-22.

You can preview each template and also edit it. You can also duplicate the template (and edit the copy if needed). Duplicating the template pushes the copy into the list of available portals. You can then check the box on the left side of a portal in the list and click Add to Location at the bottom of the page. A new page appears that allows you to select the locations where the portal will be valid. Click Save Changes to validate.

DNA Spaces does not provide bandwidth policies like CMX does. The only accessible filter is to allow direct or indirect connection to the Internet. During the portal customization phase, you can click the Get Internet module and configure there whether access will be direct or if users will be redirected to another web server after the login completes.

Implementing WIPS on MSE

Wireless Intrusion Prevention System (WIPS), also called adaptive wireless intrusion prevention system (AWIPS), has a complex history on Cisco systems. You need to keep in mind that wireless intrusion detection relies on the concept of signatures. Each attack leverages specific frames that are sent (or replayed) with an identifiable target source or destination, and at a particular pace, that can be uniquely identified (thus representing the signature of an associated attack). Over the years, as new attacks appeared and were analyzed by Wi-Fi researchers, Cisco implemented their matching signatures in a central database and the most common signatures directly on the WLC. Today, after more than 20 years of Wi-Fi development, the central database includes more than 260 signatures, and the WLC includes 17 signatures. However, many of them match attacks that would not occur on a modern network. For example, some signatures match the detection of WEP 40 implementations. Such a weak protocol has long been considered obsolete and is equivalent to “no protection.” The tool to detect this implementation only runs on Windows 2000 and earlier. As such, it is unlikely to occur in today’s deployments. In summary, it is time to update these signatures and those that are obsolete. Cisco is working on this update. In between, you can find the full AWIPS on CMX/MSE 8.x but not on the 10.x generation (yet). In parallel, the essential WLC signature set is still present in AireOS WLCs but is not implemented (yet) in the Catalyst 9800. As the new signature set gets finalized, it will be implemented on the new platforms, and the traditional platforms will progressively be updated.

AP Deployment for WIPS

Still, as a networking professional, you may be asked to implement AWIPS, and you need to know that this requirement means deploying CMX 8.0 with AireOS. You also need to understand the logic of WIPS. In such a deployment, you configure CMX, acting as the signature central database, to activate the detection of attacks that matter to you. In most cases, these are a subset of the 261 known attacks that CMX can detect. CMX then deploys these signatures to the WLCs and associated APs of your choice. These APs need to be able to identify specific frames’ patterns and match them against known attack signatures. This task requires each AP to be available to observe the air long enough to make such pattern matching. As such, you can apply WIPS on your APs, but their efficiency will depend on the mode in which they operate:

In Local (standard) mode, the AP focuses on client data service on a specific channel. The AP only has limited time to observe the channel and make pattern observations. The AP scans other channels at intervals as part of RRM but spends only a few tens of milliseconds on each other channel, thus making attack detection unlikely (or slow). WIPS can work but is least efficient in this case, and attack detection may be slow.
In Enhanced Local mode (ELM), also called Local-WIPS mode, the AP still performs client data servicing, but when scanning off-channel, the radio dwells on the channel for an extended period of time, allowing enhanced attack detection. If you deploy WIPS on some APs, you should prefer ELM to Local mode.
In Monitor mode with WIPS, the AP is fully dedicated to attack detection and mitigation. This is, of course, the most efficient mode, but the AP does not provide client data service anymore. Note that your AP can be in regular Monitor mode (with “None” as submode) and then only perform RRM-focused monitoring. You need to set the monitor AP to WIPS submode in order to make it a full-time WIPS AP.
You can also install a radio module on some AP models (Aironet APs 3600 and 3700), called Wireless Security Module (WSM). This module is in Monitor WIPS mode all the time, while the main AP can stay in another mode.

You do not need to apply WIPS mode to all your APs. In a standard deployment, WIPS is treated like any other rogue detection system. You need enough WIPS APs to monitor the entire coverage area, but you also need to keep in mind that most attacks are performed using management frames. These frames are usually sent at the lowest configured mandatory data rate, which is usually 6Mbps. Perform a site survey and ensure that your WIPS APs can detect traffic sent at low data rates (for example, 6Mbps). Such a requirement typically results in fairly large cells, between 10K and 26K square feet each in 2.4GHz (depending on the floor layout and building material) and between 4.5K and 26K square feet in 5GHz (assuming an attacker is sending traffic at 15 dBm). In an office deployment, this size means that you will deploy one WIPS for every five standard (Local mode) APs.

It is clear that the final density will depend on your building layout, and you should survey before making the density decision. You should also keep in mind that some attackers will (purposely) use lower-power devices in order to escape your detection or send their management frames at higher rates (such as 24 or even 54Mbps). You should also consider the location sensitivity and the cost of successful attacks before deciding on a deployment scheme.

CMX WIPS Configuration

WIPS activation is done from Cisco Prime Infrastructure, when you’re adding the MSE, in Services > Mobility Services Engine. After entering the MSE details (name, IP address, admin username and password), and after adding the WIPS license, in Select Service, choose WIPS, assign the maps (campus, buildings, and floors) that you want under the WIPS service, and then click Synchronize to activate WIPS for these locations.

You also need to decide which APs are set to ELM and Monitor mode. The configuration is individual to each AP. From Wireless > Select AP, set the AP mode to either Local or Monitor and set the submode to WIPS. The same task can also be done from Cisco Prime Infrastructure.

The next and main task is to configure a WIPS profile from Cisco Prime Infrastructure. In the Services > Mobility Services > wIPS Profile page, select Add Profile and click Go.

Because it is unlikely that all 261 known attacks will be relevant to you, and because the sensitivity of the detection also depends on your environment, PI allows you to choose a template from which to build your WIPS profile, as shown in Figure 14-23.

In most cases, you would use the template that best matches your environment type and then customize it to your needs. Such a course of action saves you time, as customization allows you to change the profile at will, adding, removing, or editing attack parameters as needed. This way, you could conceptually change the content of one profile into another if you decided to do so. In other words, using a template does not constrain your profile but saves you time by presetting it with attacks and parameters that are commonly of concern for the target environment.

Therefore, you should enter a name for your profile in Profile Name, select the environment template that best matches your environment description, the choose Add and Edit to customize the profile.

The WIPS wizard then displays a list of SSID types. This page is useful to seed WIPS with the names of SSIDs that you know and that have a clear meaning in your environment. For example, if your network includes the Corporate and Research SSIDs, check the box on the left of MyWLAN, and in the upper right drop-down list choose Edit Group and click Go. Then, in the new window, enter your SSID names, one per line, and click Save to validate. If your guest SSID is called CompanyGuests, check the box on the left of the Guest category and repeat the same process done previously, as displayed in Figure 14-24.

WIPS offers five SSID categories:

MyWLAN: For your corporate SSIDs, typically with encryption (WPA2/WPA3) and authentication (PSK/802.1X).
Guest: For your WebAuth-based SSIDs.
Neighbors: For SSIDs that are known in your environment but do not belong to you. In most cases, you will want to exclude these SSIDs from active protection, as your neighbors may be adding, removing, or changing AP parameters for these SSIDs, without these changes being a cause for alarm.
Any: For SSIDs that you know and for which the previous categorization is not relevant (for example, when guest and corporate users are sent to the same SSID, or in cases where some SSIDs may have more than one meaning).
Other: For all other SSIDs.

You can also create your own group or delete existing groups. These group names are not constraining; they are just suggested categories. In a later phase, when you manage your alarm and the expected intrusion prevention action, you can assign each action to one or more of the SSID types. In other words, these groups are only a convenient way for you to group alike SSIDs in common containers.

Once you have defined your groups and their associated SSIDs, click Next. In the new page, all the known attacks are displayed on the left column, organized in categories. You can click each attack to see details on the right part of the screen, including the threshold (how many detections per sampling period would trigger the alarm), the severity, the SSID group to which the alarm applies, and the action to take when the alarm is triggered (notify or contain). An example is shown in Figure 14-25.

In most cases, your initial configuration task would be to click each attack, in turn, carefully read the description in the bottom-right part of the screen, and decide if detection of that attack is relevant in your environment and for which SSID groups the detection is needed. Then you would edit the attack parameters to match your environment detection needs. This initial configuration task is time-consuming but necessary to adapt WIPS to your environment. If you need different thresholds for different SSID categories, you can also add policy rules and their associated SSID groups, detection thresholds, and action.

Note

It may be tempting to think that all attacks are relevant and worth detecting. Although this thought is likely true conceptually, you should also keep in mind the outcome of each detection and the likelihood of each attack in your environment. For example, if your corporate WLANs implement WPA3/802.1X on 802.11ax/Wi-Fi 6 and Protected Management Frames (PMF), then a man-in-the-middle attack (as detected by attack ID 64) is simply not possible (as your clients ignore spoofed management frames), and you are wasting detection resources. Similarly, implementing detection of Soft APs (attack ID 99) in an environment where people are allowed to use tethering on their personal devices (for example, a public venue) will generate a large number of alarms with no clear action to take as a result of such detection.

There are two types of monitoring objects: SSID Group and Device Group. Depending on signatures, it can be that neither, one, or both are available to be configured. The Device Group is a list of device MAC addresses that you want to monitor for attacks. You can edit the groups and manually enter the MAC addresses of assets to protect. Alternatively, if your assets are all infrastructure devices, such as APs and their clients, you can use the Internal option as the Device Group to be monitored.

The Severity value represents the classification of the associated alarm. In Cisco Prime Infrastructure, each alarm category matches one or more reporting mechanisms, from simple display in the dashboard to SMS or email alerts. It is expected that alarms with higher severity would need faster reporting, because an immediate action may need to be taken. Besides reporting, an additional option for some alarms is Forensic. When you activate that option, the detecting APs capture, over the air, the packets that trigger the alarm and send it to the MSE, where the capture is saved for troubleshooting and analysis purposes. It is not recommended to enable Forensic for all alarms, because such capture increases the WIPS alarm-related traffic dramatically, especially in case WLC and MSE are separated in different locations and communicate over a WAN link.

Once an attack is detected, the matching alarm is triggered and surfaced in Cisco Prime Infrastructure. The alarm can be configured (beyond its severity) with additional parameters, such as the following:

Location: The location of the attacker is computed by CMX, and this location can be displayed on a floor plan. This is useful in order to physically remove the offender.
Auto-Immune: For some DoS attacks, a potential attacker can use specially crafted packets to mislead WIPS to treat a legitimate client as an attacker. This action may cause the controller to disconnect the legitimate client. The auto-immune feature is designed to ignore the crafted packets from an attacker and protect the legitimate client from loss of connectivity. This protection is valid only for reassociation messages.
Blacklist: Different from the auto-immune, blacklist is a more aggressive mitigation action to de-authenticate the identified attacking device if it is connected first, and then ignore all traffic from it afterward as long as it is on the blacklist. This protection is useful for attacks where an offender starts infrastructure services (for example, a fake DHCP or DNS server).
Containment: The containment action in WIPS attacks is similar to rogue AP containment in the WLC. It is designed to initiate containment on SSID-related attacks to prevent legitimate clients connecting to those SSIDs set up by attackers. The offender MAC address is disconnected and prevented from connecting again to the affected SSIDs.

One you have reviewed and customized the attacks, click Save to validate your changes and Next to continue. You can then select the MSE(s) and WLCs to which this profile should be applied. Click Apply to validate. As the profile is deployed to these WLCs, their internal signature detection, only allowing the detection of the 17 most common attacks, is deactivated and replaced by the WIPS profile. You can see this deactivation in the WLC by navigating to Security > Wireless Protection Policies > Standard Signatures. The Enable Check for all Standard and Custom Signatures box should be unchecked. Keep in mind that you cannot have both the MSE WIPS profile and the local WLC signature detection mechanism active at the same time. If you enable WIPS, you need to deactivate the WLC local detection tool.

Ensuring Location Operational Efficiency

At the conclusion of this chapter, your MSE and DNA Spaces should provide the components you need to act upon the detection and location of Wi-Fi devices in your environment. Although DNA Spaces does not require optimization, an on-premises MSE implementation is different, as it offers a single point of failure. Therefore, you need to ensure that MSE can continue to provide services, even in the event of failure. This requirement implies deploying high availability. Additionally, the services you will provide are only as efficient as the location you compute is accurate. You also need to make sure that the location technique you use provides the accuracy you expect.

Deploying MSE High Availability

The purpose of MSE HA is to ensure that, in the event of the main MSE failure, a secondary MSE can take over and continue performing CMX tasks. In order to maintain the failover transparent from a network connectivity point of view, the concept of virtual IP (VIP) is used. When both the primary and secondary are in the same subnet, the primary and secondary MSEs are identified as a single VIP. This VIP is mapped to the real IP of the running primary CMX. When failover happens, VIP is remapped to the address of the secondary CMX. It is not mandatory to use a virtual IP. If you are doing CMX Layer 3 high availability (that is, having the two servers in different subnets), you cannot use a virtual IP. The virtual IP provides a unique IP for the IT admin (or Prime Infrastructure / Cisco DNA center) to manage CMX regardless of a failover or failback. The WLCs, however, will have an NMSP tunnel only toward the currently active CMX physical IP address.

To install HA MSEs, start by installing the primary MSE as described in Chapter 13. Once the installation completes, install the second MSE. During the installation process, select the MSE as a secondary server for high availability, as shown in Figure 14-26.

At any point of the installation (on the primary or the secondary server), you can connect to the MSE web interface using https://mse_ip_address:1984/andfollowtheinstallationprocess. Once the installation completes, you can connect on port 4242 (https://mse_ip_address:4242) to access the HA interface. On the primary server, connect using the cmxadmin account and enter the secondary server IP address, along with the virtual IP address that both servers should share, the password for the cmxadmin account on the secondary server, and the failover type. Auto-failover will allow CMX to automatically fail over to the secondary server when a serious issue is detected. Manual failover will require the user to initiate the failover from the web interface or command line. The failure will be reported to the user via notifications, but no action is taken for manual failover.

You can also inform the notification email address—the email address where you send notifications about HA information or issues. The email settings used for HA are the same as CMX. This field is required even though you don’t have an email server configured. Feel free to enter a dummy email address and click “enable” if you don’t intend to use email notifications.

The initial synchronization of all the data between the primary and secondary server can take a significant amount of time to complete. The user interface will indicate the state as “Primary Syncing” while the synchronization is being done. When the synchronization has completed successfully, the server on the primary will enter the state “Primary Active.” When completed, an information alert will be generated in CMX. In addition, an email alert will be sent that indicates that the system is active and syncing properly.

Your MSE pair is not ready for high availability. When the primary MSE fails, failover occurs and the secondary MSE becomes active. A failover can occur automatically when CMX detects an issue with the primary server. A failover can be done manually by a user in the web user interface or on the command line. The progress of the failover can be monitored based on the current state of each system.

To start the failover manually, log in to the CMX HA web interface on the primary or secondary (https://server_ip:4242). The monitor page will have a button labeled “Failover” if the servers are actively syncing.

Running CMX on the secondary MSE should be considered a temporary situation until the root cause of the primary failure has been identified. Once the primary box is restored (or a new box is provided), the failback process should be initiated. The other option is to convert the system to a primary and replace or convert the other system to a secondary server. In either case, a server should be made available as soon as possible since HA is no longer syncing to a secondary server. The failback process must be manually done by the user. To initiate failback, log in to the CMX HA web interface on the primary or secondary (https://server_ip:4242). The Monitor page will have a button labeled “Failback” if both the servers indicate that a failover is active.

Note that these are your only tools to monitor or manage failover. There are equivalent CLI options provided at the end of this chapter, but there is no troubleshooting or specific monitoring tool to check the synchronization progress between MSE copies. Also keep in mind that you need to disable HA before upgrading your CMX code. If you forget to disable HA, the upgrade script will remind you. Make sure to upgrade both CMX instances to the same code version.

Managing Location Accuracy

Most services examined in this and the previous chapter rely on the fundamental principle that location is performed and is accurate to the level you have configured (Presence, RSSI trilateration with or without FastLocate, and Hyperlocation). At the same time, indoor location does not defy the laws of physics. Accurate location cannot happen if your deployment is subpar. Therefore, you need to make sure you have enough APs, that they are positioned properly, and that the location engine has enough information to compute clients’ positions.

Location Requirements

AP position and density are the first elements you should keep in mind when you suspect that location is not optimal. As you’ll recall from Chapter 3, “Conducting an Onsite Site Survey,” and Chapter 6, “Designing Radio Management,” APs should not be set in a straight line but should form a convex hull within which location is possible. At each point of your floor where you want location to be possible, there should be at least four APs, one within each quadrant, as shown in Figure 14-27. Three of these four APs should be within a 70-foot range (the ideal range is 40 to 70 feet).

This location readiness can be verified from Cisco Prime Infrastructure. From the PI Maps > Site Maps (New) page, click a floor plan of your choice. In the upper-right corner of the page, in the Tools menu, select the option Inspect Location Readiness. The system will compute, for each point of your floor, the APs’ distance and positions and will color green the areas that match the location requirements, as illustrated in Figure 14-28.

This test does not guarantee location accuracy within the green zone. It simply displays in red areas where location is unlikely to be possible or provide usable results. In the green zone, you have enough APs to perform location if the area is an open space. PI does not take the walls into account and also does not know if the APs are really where the map reports them.

Verifying AP Settings

Your next step is to examine each AP on the map and verify that it matches the location and position of your APs in the real world. In the upper-right corner of your floorplan view, select the Edit button and choose to edit the APs’ positions. Carefully verify that each AP icon position matches the real AP position on your floor. Also verify the AP height, keeping in mind that no accurate location will occur if the AP is positioned more than 20 feet above the height of your clients.

Note

This requirement is usually simplified as “not higher than 20 feet (approx. 6 meters) above the ground.” Most clients are carried at 2 to 3 feet (60 to 90 cm) height, but this detail does not matter. What this rule expresses is that, as the distance from the AP increases, the signal decreases fast at first, then more slowly (it follows a log curve, as seen in Figure 13-1 of Chapter 13). If your AP is too high, then most clients’ signals are weak in general without a clear difference as a client moves. This reduces ranging accuracy.

You should also verify the AP orientation, as shown in Figure 14-29. The azimuth represents the horizontal orientation of the AP. Each AP has a Cisco logo with the word “Cisco” printed below the logo. When you hold the AP in front of you and read the word “Cisco” (with the correct orientation), the bottom part of the AP represents the direction of the azimuth arrow in PI. Therefore, if your AP is mounted flat on the ceiling and the “bottom” (now horizontal) points toward the west, then in PI the azimuth arrow should also point toward the west for that AP. Such orientation is not important for indoor APs with omnidirectional antennas, but it is fundamentally important if your AP incorporates Hyperlocation capabilities. An error of a few degrees in the arrow direction may result in poor location accuracy.

You can also set the tilt, or elevation. If your AP is not mounted flat on the ceiling, the elevation represents the angle of that “bottom” part of the AP with the horizontal axis. If your AP uses external antennas, all these operations should apply to the AP antenna (not to the AP body), as the antenna is the RF part of the AP.

Once these operations are performed, synchronize your results with MSE (in PI, select Services > Location Services > Select MSE > Synchronize).

Verifying Location Accuracy on MSE

You can continue your verifications from CMX. From the CMX activity map, on a floor map, locate and click a client, as shown in Figure 14-30. Then, in the upper-right corner of the screen, click the blue geolocation icon.

A pop-up window appears, asking you to name the test. Enter a name of your choice in the Enter the test name field. Then position the bottom tip of the geolocation icon at the exact location where your client is positioned. Do not move the client, and let the test run for a while. The tool will collect signal samples from the client and perform 20 location computations before displaying a results table that shows, for each location computation result, the interval since the previous computation (called Location Computation Frequency in seconds), the percentage of time that the client was evaluated to be on the correct floor, the percentage of time the computation produced a client location estimation within 30 feet (about 10 meters) of the actual location (the tip of your geolocation icon), the average distance error for that estimation, and then the error for the best 90 percent estimations, the best 75 percent estimations, and the best 50 percent estimations.

If the results do not match your expectations, after having verified again the position and orientation of your APs, you should also verify onsite that, from the target locations, at least four APs are around the client, three of which are at 70 feet (approx. 21 meters) or less apart. You should also verify that the AP signal is at −72 dBm or higher. Too weak a signal reveals a density of obstacles that may prevent proper signal reception on the APs.

Note

You will see different values for this signal level. Some references will refer to −75 dBm, and they mean the minimum signal (signal should be at least at −75 dBm). Others will mention −72 dBm as the “preferred” minimum, meaning that −75 dBm is acceptable, but −72 dBm will provide a better location estimation. Also keep in mind that this is the signal of the client on the detecting APs, not the signal of the AP at the target location. So you should make sure to connect the client to an AP and use the WLC GUI or CLI to check the client signal at that AP.

Customizing RF Calibration Model on PI

If the signal is within the appropriate range, then a last task is to refine the RF calibration of your floor. As detailed in Chapter 13, each floor has obstacles (walls and such) that affect signal propagation and that are accounted for when you add a floor map to a building in PI, with an associated RF calibration model. If location is inaccurate, it may be that the RF model you chose does not work for your floor, and you need to create your own. To do so, you need a client that supports Cisco Compatible Extensions, such as an Intel adapter. Then, in PI, navigate to Map > Site Maps. From the Select a command drop-down list, choose RF Calibration Models and click Go. From the Select a command drop-down list, choose Create New Model and then click Go. Enter a model name and click OK. The new model appears along with the other RF calibration models with a status of Not Yet Calibrated. Click the model name to open the model name page. From the Select a command drop-down list, choose Add Data Points and click Go. Enter the MAC address of the device being used to perform the calibration, and then choose the appropriate campus, building, floor, or outdoor area where the calibration is performed. Then click Next to start.

Note

It is best to perform these steps from the laptop you will use for the calibration task. If you are connecting to PI from that laptop, its MAC address will automatically be populated in PI.

Click your real location on the map and click Go. PI will compute your location and modify its model to account for your real location. You will need to collect at least 150 points per band for the calibration to complete. The tool offers point calibration options, as described here, or linear options (where you click a starting point and then a stopping point after walking in a straight line).

Once your point collection completes (the point collection status bar next to the floor map appears as filled in green), click the name of the calibration model at the top of the page to return to the main page for that model to calibrate the data points, and then choose Calibrate from the Select a command drop-down list and click Go. The process can take a while. PI will recompute the RF model based on your data collection. At the end of the calibration phase, you can click the Inspect Location Quality link to see a map showing the RSSI readings. If there are areas where location accuracy is poor (area shows in red), you need to go back to that location and collect more data points to help PI refine the model. Once all areas are green, to use the newly created calibration model, you must apply the model to the floor on which it was created (and on any other floors with similar attenuation characteristics as well). Choose Monitor > Site Maps and find the specific floor to which the model is applied. At the floor map interface, choose Edit Floor Area from the drop-down list and click Go. From the Floor Type (RF Model) drop-down list, choose the newly created calibration model. Click OK to apply the model to the floor.

This process can be repeated for as many models and floors as needed. After a model is applied to a floor, all location determination performed on that floor is done using the specific collected attenuation data from the calibration model.

Verifying Hyperlocation Configuration

If you use Hyperlocation (or FastLocate), do not forget to enable that feature. This can be done globally for all APs on the WLC in Wireless > Global configuration, per AP group in WLAN > AP group > Edit, or per AP in Wireless > Edit AP > Advanced. In the WLC, Packet Detection RSSI Minimum is set by default to a low value (−100 dBm). It may be worthwhile to increase the value to the threshold where a client should not be in your network anymore (for example, −82 dBm).

On your WLC, you should see that Hyperlocation is enabled by using the command show advanced hyperlocation summary, as shown in Example 14-1.

Example 14-1 Output of the show advanced location summary Command

Click here to view code image

(Cisco Controller) >show advanced hyperlocation summary

Hyperlocation.................................... UP

Hyperlocation NTP Server......................... 172.31.255.1

Hyperlocation pak-rssi Threshold................. -80

Hyperlocation pak-rssi Trigger-Threshold......... 10

Hyperlocation pak-rssi Reset-Threshold........... 8

Hyperlocation pak-rssi Timeout................... 3

AP Name               Ethernet MAC     Slots    Hyperlocation

----------------   ------------------- -------  ------------

AP00aa.bbbb.cccc    00:aa:bb:bb:cc:cc     3          UP

On MSE, you should also be able to verify that the Hyperlocation service is running with the command cmxctl status. This command produces a long output. Verify that Location and Hyperlocation services are running. If these services are not running, your MSE configuration may need to be verified (and MSE may need to be restarted).

You can also capture on the MSE network interface traffic coming from the WLC and verify that there is traffic sent to port UDP 2003 with the following command:

Click here to view code image

tcpdump -i eth0 dst port 2003 -w test.pcap

You can then open the test.pcap file (for example, with Wireshark). You should see traffic sent from your WLC IP address to the MSE IP address on port UDP 2003. You cannot see the content of the packets, as they are encrypted, but their presence shows that AoA information is reaching the MSE.

Also make sure to use NTP time synchronization on the WLC, PI, and MSE. Keep in mind that Hyperlocation only works with on-premises MSE, not with DNA Spaces Cloud without MSE.

Beyond AP placement on PI and synchronization between PI and MSE, the most common issues are Hyperlocation not enabled on the WLC and improper NTP configuration on one of the devices. Check for these elements, and you should be able to face the CCNP Enterprise questions and any location accuracy issue in real deployments.

Summary

This chapter described advanced location services available on CMX and DNA Spaces. In this chapter you have learned the following:

The main services available in CMX and DNA Spaces
How to deploy Analytics services
How to deploy location-specific guest portals
How to configure AWIPS on the MSE
How to ensure MSE efficiency and location accuracy

References

For additional information, refer to these resources:

CMX Configuration Guide: https://www.cisco.com/c/en/us/td/docs/wireless/mse/10-6/cmx_config/b_cg_cmx106.html

Guest access configuration in C9800: https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/config-guide/b_wl_16_10_cg/cisco-guest-foreign.html#concept_e5l_1np_njb

WIPS deployment guide: https://www.cisco.com/c/en/us/td/docs/wireless/technology/wips/deployment/guide/WiPS_deployment_guide.html#pgfId-43454

CMX HA guide: https://www.cisco.com/c/en/us/support/docs/availability/high-availability/213664-configure-cmx-high-availability.html

DNA Spaces Configuration Guide: https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Mobility/DNA-Spaces/cisco-dna-spaces-config/dnaspaces-configuration-guide.html

Calibrating RF models: https://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/infrastructure/3-0/user/guide/pi_ug/wireless-maps.html

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a few choices for exam preparation: the exercises here, Chapter 18, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep Software Online.

Review All Key Topics

Review the most important topics in this chapter, noted with the Key Topic icon in the outer margin of the page. Table 14-3 lists these key topics and the page numbers on which each is found.

Table 14-3 Key Topics for Chapter 14

Key Topic Element	Description	Page Number
List	CMX object types	335
List	CMX Connect configuration procedure	343
Paragraph	AireOS vs. C9800 ACLs	346
Paragraph	CMX Portal library	346
Paragraph	DNA Spaces portal creation	349
List	AP modes for WIPS	352
Paragraph	CMX WIPS profiles	353
Note	Limiting attack detection scope	355
Figure 14-27	Location readiness checklist	359

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

perimeter

zone

preauthentication ACL

Enhanced Local mode