Prime Infrastructure and MSE/CMX

Basic Operations

Although the features and operations described in the following paragraphs are introduced as “basic,” they still represent the foundation for properly working with Cisco Prime Infrastructure. CCIE Wireless candidates may find them crucial to speed up workflows during the lab exam too.

Working with Devices, Templates, and Audits

After having established how to manage administrative access to the management tool, one of the next steps is to use it for managing network devices. In Prime Infrastructure, you can configure a WLC through pages with a similar look and feel as the WLC’s GUI. However, one of Prime Infrastructure’s main advantages is to push multiple configuration changes at once to multiple WLCs; such a task can be achieved through the configuration templates.

Prime Infrastructure communicates with the WLC through SNMP. A WLC can send SNMP traps to Prime Infrastructure, or NetFlow records too for Application Visibility and Control (AVC) statistics. Even though Prime Infrastructure optionally asks for credentials to access a WLC via telnet/SSH/HTTPS when adding the WLC to the list of managed devices, these credentials are not needed: all monitoring operations, configuration changes, and even traps from the WLC take place via SNMP.

Common best practices when configuring SNMP communication between a WLC and Prime Infrastructure include the following:

• Use SNMPv3 whenever possible, disable SNMPv1/v2c, and remove all communities on the WLC.

• If SNMPv3 is not an option, use SNMPv2c, disable SNMPv1, and change the default communities with strong keywords and very selective subnet filtering.

• Keep unused SNMP trap controls disabled on the WLC.

• Use CPU ACLs on the WLC to restrict traffic from unneeded sources, which are not Prime Infrastructure or other network resources (more on this on Chapter 4, “AireOS Appliance, Virtual, and Mobility Express Controllers”).

To accelerate the process of importing multiple network devices sharing the same SNMP configuration and credentials, Prime Infrastructure supports credential profiles. You can create a credential profile under Inventory > Device Management > Credential Profiles and specify just once the SNMP parameters, as well as telnet/SSH and HTTP/HTTPS credentials if needed; when adding a network device to Prime Infrastructure, you can then select a previously configured credential profile instead of retyping the parameters every time.

On top of using credential profiles, you can also import multiple network devices in parallel, through a CSV file containing the same values (IP address, SNMP parameters, CLI credentials, and so on) that you would use to add those devices through the GUI.

After having added a WLC, you can apply configuration changes either through the view of the WLC itself in Prime Infrastructure or through templates. The latter is usually one of the main reasons to use Prime Infrastructure instead of going directly through the WLC’s GUI. Templates are a set of configuration tasks for specific features, which can be applied to one or more WLCs in parallel. You can create configuration templates for the WLC under the menu Configuration > Templates > Features & Technologies by browsing to the different categories under Features and Technologies > Controller in the Templates list. On top of WLC templates, you can also push templates for autonomous and lightweight access points, under the menus Configuration > Templates > Autonomous Access Points and Configuration > Templates > Lightweight Access Points, respectively.

You can deploy templates right away or schedule them for predetermined times and dates. This option enables you to address requests, such as enabling specific AP radios only during certain times of the day, through a Lightweight Access Points template, for example. You can find back scheduled AP templates and other tasks under the menu Configuration > Templates > Scheduled Configuration Task.

Aside from manually creating new templates, if you already configured any objects or features on the WLC before adding it to Prime Infrastructure, you can also automatically create a template for each already configured element (WLANs, RF profiles, ACLs, and so on). This process goes under the name of templates discovery, and you can launch it from the menu Monitor > Managed Elements > Network Devices by selecting the category Wireless Controller in the left panel for Device Groups, then selecting your WLC in the list and clicking Configure > Discover Templates from Controller through the option on the top right of the menu. Figure 6-4 shows an example of templates discovery in Prime Infrastructure.

Figure 6-4 Templates Discovery Option from a WLC

After you have discovered configuration templates from a WLC, you will be able to reapply those templates and features to other WLCs, either one by one or by groups, through the Wireless Configuration Groups. You can create configuration groups under Configuration > Wireless Technologies > Wireless Configuration Groups and specify either manually created or discovered templates.

After configurations have been deployed, you can keep track of potential changes through auditing options. Under the menu Inventory > Device Management > Network Audit you can retrieve almost real-time logs on network changes, or you can also find them through the Reports > Report Launch Pad, under Compliance > Change Audit. For more proactive auditing, you can also enable notifications via syslog as changes occur; such an option is available under Administration > Settings > System Settings > Mail and Notification > Change Audit Notification.

Operating Maps

Another major interest of operating your Cisco wireless deployment through Prime Infrastructure is the additional visibility into your RF environment, rogue APs, clients, and so on when using maps.

Fundamentally, a map is a floor plan where you can place your APs. In Prime Infrastructure’s internal hierarchy and configuration, a floor needs to be part of a building, which can optionally be part of a campus. You do not need to import images for campuses and buildings, but you should import background images for floor plans before starting to place APs. When configuring dimensions for campuses, buildings, and floors, the default scale unit is in feet. You can change this to meters under the menu Maps > Wireless Maps > Site Maps ( New! ) by selecting your campus and then the option Units of Measure through the Map Properties gear icon on the top right of the page.

Among the final steps of a map creation, Prime Infrastructure asks you to launch the map editor to rescale the map with a ruler tool, define obstacles, zones, GPS markers, and other properties. The following are best practices for most deployments: scaling maps is key for location calculations in CMX, and although obstacles do not affect calculations for location services, they do improve the accuracy of RF heatmaps.

On top of obstacles, you might also want to add at least three GPS markers from the beginning, even before starting to place APs on the map. These GPS coordinates are exported with the map properties when working with CMX and will be available in the CMX APIs. When development teams retrieve GPS markers from a map and the client’s location coordinates on that map, they are therefore indirectly able to calculate the GPS position of the client too.

After having configured all the necessary maps, placing and orienting APs may be considered one of the most boring and repetitive tasks in the daily job of a wireless expert. Nevertheless, the precision and commitment you apply in such a task will determine the accuracy level of RF predictions, clients’ location, rogue APs location, and so on. APs can be placed on a map only if they have registered to a WLC managed by Cisco Prime Infrastructure at least once, even if for a short period of time, and even if the APs were taken offline right after the registration. Prime Infrastructure needs to “see” them once. This can facilitate deployments where you need to send APs to site relatively quickly while carrying on working proactively on their placement before the team on site installs them. You can, for example, register APs to your WLC in the lab, or other prestaging facility, get them “seen” by Prime Infrastructure, and then unplug them to send them to site. While APs are on their way to the final deployment site, you can keep working on their placements on the maps. Placing and orienting APs on maps does not affect any configuration or Radio Resource Management (RRM) calculations on the WLC. An APs’ placement is used by Prime Infrastructure to predict RF heatmaps, and by CMX to calculate location coordinates.

When positioning an AP on a map in Prime Infrastructure, one setting can be changed and pushed to the WLC’s configuration for that AP: the antenna model selection. If you specify the antenna model from the AP’s positioning options (see Figure 6-5), Prime Infrastructure will automatically push the antenna to gain configuration to the WLC. This particular behavior is present with what we will refer to as the “old” generation of maps under Maps > Wireless Maps > Site Maps (Deprecated), and you can see a quick example of it in Figure 6-5.

Figure 6-5 Antenna Model Selection for Old Generation Maps

Version 3.2 of Prime Infrastructure introduced a “new” generation of maps, as shown in Figure 6-6, which do not push the antenna gain to the WLC when the antenna model is configured, while placing an AP on a map. You can access new generation maps under Maps > Wireless Maps > Site Maps (New!).

Figure 6-6 Antenna Model Selection for New Generation Maps

However, if you still use the old generation of maps, also available in version 3.2 (or any previous version up to 3.1.x), modifying the antenna model when placing the AP on a map also pushes that configuration to the WLC. Another common technique for configuring an antenna model, both on Prime Infrastructure’s maps and on the WLC, is to create a Lightweight Access Points configuration template, where you can configure the antenna models under the 802.11a/n/ac and 802.11b/g/n tabs.

Along with AP placement, antenna orientation is the other essential operation for obtaining realistic heatmaps and accurate clients, interferers, and rogue APs location on maps.

When orienting an antenna, keep in mind some rules to help you:

• For the vast majority of installations, you might need to configure the orientation of both antennas, on the 2.4 GHz and on the 5 GHz radios. If one radio is disabled, you might want to ignore its orientation; however, it is recommended that you orient all antennas, even those that are disabled, just in case you enable them in the future.

• There are two orientations for each antenna: azimuth and elevation. Azimuth is the antenna orientation viewed from above, and elevation is the antenna orientation viewed from the side. You can visualize the orientation of an antenna as an arrow, which you can represent in different ways, depending on the type of antenna.

• When configuring orientations, you should first position the azimuth and then the elevation; such an order is logically easier to follow. Therefore, you can first imagine orienting the antenna’s arrow as viewed from above and then as viewed from the side.

• For APs with internal antennas, the orientation is represented by an arrow beaming from the middle of the AP (where you can often see the Cisco logo or the LED) and pointing toward the upper side of the AP, and toward where all the Ethernet ports are for the vast majority of indoor AP models up to the 1800/2800/3800 series, as shown in Figure 6-7, for example.

  

  Figure 6-7 Antenna Orientation for APs with Internal Antennas

By default, Prime Infrastructure orients an AP with internal antennas with an azimuth of 90 degrees and an elevation of 0 degrees. This corresponds to an AP mounted with the upper side of the Cisco logo pointing south (toward the lower part of the floor map) and the Cisco logo facing down to the ground. It’s the typical installation of an AP on the ceiling, and Figure 6-8 shows an example of such an orientation in Prime Infrastructure.

Figure 6-8 Antenna Orientation for a 3700 Series AP on the Ceiling with the Upper Side of the Cisco Logo Pointing South and Its Ethernet Ports Facing South Too

Omnidirectional antennas, as their name suggests, radiate in all directions. Therefore, suppose the real azimuth of an AP with internal omnidirectional antennas is different from what you configured on the map. For example, you may have wrongly configured an azimuth of 180 degrees (the Ethernet ports show as facing west, while actually mounted facing south). Despite this difference, the heatmap prediction or location services should still be accurate, precisely because of the omnidirectional nature of the antennas. Nevertheless, we recommend making the extra effort of configuring both azimuth and elevation to reflect the real antennas’ orientations.

This care in antenna orientation is especially important for APs and antennas mounted on walls. For example, suppose that an AP with omnidirectional antennas is vertically mounted on an east wall, with the Cisco logo facing west and the Ethernet port(s) facing up to the ceiling. You should configure an azimuth of 180 degrees (that is, first the arrow pointing left, as viewed from above) and an elevation of 90 degrees (that is, the arrow pointing up as viewed from the side), as shown in Figure 6-9.

Figure 6-9 Antenna Orientation for an AP on an East Wall with the Cisco Logo Facing West

• For external dipole omnidirectional antennas (AIR-ANT2524DB-R, AIR-ANT2524DG-R, and AIR-ANT2524DW-R), you should think of the arrow as perpendicular to the longitudinal axis of the antenna and to either of its “flat” sides. By default, Prime Infrastructure orients external dipole antennas with an azimuth of 90 degrees and an elevation of 0 degrees. This corresponds to the antenna’s tip pointing down to the ground and either of its “flat” sides parallel to the X axis of the map. When using external antennas, the AP orientation does not matter, because only the external antenna’s installation and orientation determines the coverage area.

  As an example, a dipole antenna with an azimuth of 0 degrees and an elevation of 45 degrees corresponds to the “donut” shape coverage area tilted down to the left, when looking at it from the south side of the map. You can see an example of this configuration in Figure 6-10.

  

  Figure 6-10 Dipole Antenna Orientation with an Azimuth of 0 Degrees and an Elevation of 45 Degrees

  Another example, as shown in Figure 6-11, could be a dipole antenna with an azimuth of 0 degrees and an elevation of −45 degrees, which corresponds to the “donut” shape coverage area tilted down to the right when looking at it from the south side of the map.

  

  Figure 6-11 Dipole Antenna Orientation with an Azimuth of 0 Degrees and  an Elevation of −45 Degrees

  In the previous examples, to get an elevation of −45 or 45 degrees in the actual installation, you will have to turn the dipole in such a way that the antenna’s bolt will allow you to tilt it. The arrow orientation does not change between one side and the other, because you are dealing with an omnidirectional antenna.

• External patch-like antennas (AIR-ANT2524V4C-R, AIR-ANT2566P4W-R, AIR-ANT2566D4M-R, and AIR-ANT2513P4M-N) have an orientation arrow originating from the center of the antenna’s plate, perpendicular to the plate (pointing away). By default, Prime Infrastructure orients such antennas with an azimuth of 90 degrees and an elevation of 0 degrees, as shown in Figure 6-12. This means that the antenna is vertically mounted, with the plate facing south and its cables (for example, for an AIR-ANT2566P4W-R) pointing down to the ground (the orientation arrow points south as well).

  

  Figure 6-12 Patch Antenna Orientation with an Azimuth of 90 Degrees and an Elevation of 0 Degrees

  Similarly, an AIR-ANT2566P4W-R with an azimuth of 90 degrees and an elevation of −90 degrees, as in Figure 6-13, would be mounted with its plate facing down to the ground and the cables’ side pointing north: the orientation arrow in such a case would point down to the ground too. This would correspond to an antenna horizontally mounted, on the ceiling for example, with its cable connectors pointing north on the map.

  

  Figure 6-13 Patch Antenna Orientation with an Azimuth of 90 Degrees and an Elevation of −90 Degrees

Even though antenna orientations may not sound very intuitive at the beginning, one of the best ways to get a consistent grasp on them is to try out different combinations in Prime Infrastructure and check how the predicted heatmap varies accordingly.

High Availability

For additional redundancy and availability, you can deploy Prime Infrastructure servers as HA pairs: the high availability model is always with two servers, one active and one standby. The monitoring and synchronization services between primary and secondary servers are SSL based and run on TCP ports 1522 (Oracle/JDBC database connections) and 8082 (health monitoring via HTTPS). The two servers need IP reachability, of course, and if you choose to deploy them on the same VLAN, you have the option of configuring a Virtual IP for the HA pair. This option usually has the advantage of letting you point your network devices to one single management IP for SNMP traps and syslog, for example. Each Prime Infrastructure server will keep using its real management IP to source all other traffic to those network devices.

If you choose to deploy Prime Infrastructure servers on different subnets or not to configure a Virtual IP, you need to make sure that network devices are sending SNMP traps and syslog messages to the IPs of both servers, not to lose data in case of failover.

You have the option of two failover modes, manual or automatic, both having their pros and cons. Manual failover, as the word says, does not have the advantage of automatic recovery if the active server fails. However, this mode could also avoid “split brain” scenarios where each server automatically promotes itself to active because of a network reachability failure. Manual mode also avoids the issue of continuous failover because of potential network latency issues between both nodes.

The high availability configuration is relatively straightforward and can be followed through the official administrator’s guide:

https://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/infrastructure/3-2/admin/guide/bk_CiscoPrimeInfastructure_3_2_AdminGuide/bk_CiscoPrimeInfastructure_3_2_AdminGuide_chapter_01010.html#con_1104574

On top of the official guide, as a quick review of the requirements to keep in mind when setting up high availability for Prime Infrastructure, here are the main steps you should consider:

• Plan the high availability deployment model by choosing between having a Virtual IP for your pair of Prime Infrastructure servers or keeping your servers reachable on their respective IP addresses if they cannot be deployed on the same subnet.

• Verify that both your primary and secondary servers will be installed with the very same software versions, patches, and packages.

• After the primary server’s installation, while installing the secondary server, verify that you specify the option for this server to be used as a secondary for HA, and note down the authentication key that you will be asked right after this step: you will be asked for this key on the primary server when activating HA.

• After installing the secondary server and updating it, if needed, to the same version/patch/device bundle as the primary, on the primary itself, you can activate high availability through the HA Configuration tab under Administration > Settings > High Availability. You will be asked for the secondary server’s information, such as FQDN/IP and authentication key, as well as for options such as the Virtual IP or the failover mode (for example, manual versus automatic).

The high availability setup itself might take some minutes, after which you will be able to connect to your Prime Infrastructure pair either through the Virtual IP, if you chose to enable such an option, or through the primary or secondary server’s IP, depending on which one is active at a given time.

Monitoring Tools: Troubleshooting Clients and Working with Reports, Alarms and Events, and Notifications

Along with managing network devices and configurations, another main goal of Prime Infrastructure is to provide network administrators with troubleshooting and reporting tools. Although CCIE-level experts will prefer debugs on the WLC or AP, in daily network operations having a centralized tool with data from different sources could be an easier starting point to isolate issues.

Comparing troubleshooting methodologies is not the primary goal of this book, but as a general guideline, one of the fastest and easiest options for looking up a client’s details (or any other device’s details) in Prime Infrastructure is through the contextual search field on the top right of the GUI, as shown in Figure 6-14. As soon as you start typing a username, a MAC address, an IP address, and the like, Prime Infrastructure suggests any elements that are possibly related to what you are typing. This is an easy way to immediately jump to a client’s details, instead of having to navigate through a list of clients under Monitor > Monitoring Tools > Clients and Users and then filtering through specific values.

Figure 6-14 Contextual Search Field

Client details are organized in different tabs, to also provide additional logs and tools from other resources on top of Prime Infrastructure. The Overview tab consolidates information mainly from the WLC, with some details from Cisco ISE and CMX if you have integrated such solutions to Prime Infrastructure. Although these details are not in real time (as compared to WLC or AP CLI debugs), they are still a good starting point for a high-level view of policies applied to the client, for example, and in particular, to understand through which APs the client associated and disassociated (thanks to the Association History widget). Even though this is technically not a location feature, the association history might in some cases indirectly help you trace a client’s path at some levels, or even isolate whether clients are “jumping” between APs too far from one another. Complementary to these types of data, the Statistics widget, showing the client’s RSSI and SNR history, could provide useful information if your clients were experiencing radio or coverage issues, for example.

The Location tab integrates data retrieved through the former location solution Mobility Services Engine (MSE). Prime Infrastructure also supports integration with CMX 10.3 to locate wireless clients and interferences on the maps. However, location information in the client’s details (page) is available only with MSE 8.0. On top of displaying the specific portion of the floor plan, where a client is located, this page also allows you to replay the client’s location history.

Right next to location data, Prime Infrastructure also hosts a dedicated tab for reporting authentication successes and failures from ISE. From this page, you can directly monitor failure reasons and, although Prime Infrastructure displays only the main reason for the failure, you can also cross-launch the monitoring page on ISE directly to look at all the failure’s details. When adding ISE to Prime Infrastructure, you should keep in mind the following prerequisites:

• Prime Infrastructure communicates with the ISE server(s) persona running the Monitoring services.

• In case of a standalone ISE server, you can add that single ISE server to Prime Infrastructure.

• In case of a distributed ISE deployment, you should add the primary monitoring node, and the secondary too, if you want to keep collecting authentication logs in case of a failover of the primary monitoring node.

• The ISE account required by Prime Infrastructure needs to have access to the Operations tab in ISE and be part of the MnT Admin group or higher, such as the Super Admin group.

Aside from authentication logs in a dedicated tab, Prime Infrastructure also displays the policies applied by ISE during the authentication process in the client’s Overview tab. These could provide you with very useful information, such as the Authorization Profile, the Posture Status, the TrustSec Security Group, and others. Figure 6-15 shows some additional examples of tabs for client troubleshooting.

Figure 6-15 Client Details, Overview, Troubleshooting, and Other Tabs

Other tabs providing more hints on the overall client’s connection status are those for Clean Air and Events, but note that these are not necessarily in the same order as in the (WLC’s) GUI. These pages contain information about potential interferences affecting the AP where the client is connected, as well as the most recent SNMP traps (that is, events) from the WLC concerning that AP and the client.

Prime Infrastructure also has dedicated tabs for collecting and reading logs and debugs from the WLC for a specific client that you are monitoring. These are the Troubleshoot and Debug, Syslog, and RTTS (Real Time Troubleshooting) tabs. As a CCIE candidate, you will probably prefer to use CLI debugs and commands on the WLC and AP directly. Nevertheless, these tabs find their purpose for network operations teams, who can collect some initial data and open a technical support case from a single interface.

If, instead of almost real-time troubleshooting and data, you need to access historical information about clients but also networks, devices, and the like, you can rely on the reporting options under Reports > Report Launch Pad. Here you can create reports for several categories, schedule them to run periodically, and also have the report(s) sent via email after each run.

Depending on the specific category, a report includes different types of information that you can filter by customizing which columns to include in the report itself, as shown in Figure 6-16. If one of the default reports seems to have roughly the information that you are looking for, you may want to verify whether there are additional columns that you should include, through the Customize option. Under the same customization parameters, you also find the settings to sort the report’s data by specific fields.

Figure 6-16 Example of Report and Customization Options

In addition to the preconfigured reports, Prime Infrastructure supports options to composite them or create customized reports.

Under the Report Launch Pad, on the left menu, among different categories is one called Composite, with a suboption for Composite Report. Here you can select some reporting categories from different report types that should be included within a single report.

In a similar way, the Custom Reports page enables you to select some other common categories and run their data collection in the same report, instead of, for example, having to generate two or more separate preconfigured reports for each one of those. Composite and custom reports are in the end two similar options for achieving the same goal of including different categories in the same report.

If you choose to schedule reports and let Prime Infrastructure store files locally, their folder path is /localdisk/ftp/reports. You can change this, along with the files retention period, under Administration > Settings > System Settings > General > Report.

You can find even more tools for supervising network operations under the Monitor menu. On top of the preconfigured pages to monitor specific features, such as Radio Resource Management (RRM), access point radios, or even clients and network devices, through this menu you can configure events, alarms, and notifications.

Events are SNMP traps and syslog messages received by Prime Infrastructure from network devices. They are logged as events on the GUI. Alarms are alerts raised following from the correlation of one or more events.

You can configure new events to be reported, following from a specific SNMP trap under Monitor > Monitoring Tools > Alarms and Events, by clicking the Custom Trap Events button under the Events tab. Here you can either choose from some of the predefined MIBs or upload new MIBs.

Alarms are preconfigured, and you cannot create new ones. However, through specific triggers, you can change the severity of an alarm through Alarm Policies. Another option is to change the default severity of an alarm under Administration > Settings > System Settings > Alarms and Events > Alarm Severity and Auto Clear.

An alarm can have its status set to one of these three types: Not Acknowledged, Acknowledged, and Cleared. Alarms are not acknowledged by default, which means that they stay in the Alarms and Events table until some other action is taken. When you acknowledge an alarm, you remove it from the Alarms and Events table and, even if the events that generated the alarm recur again within the next 7 days, Prime Infrastructure will not trigger the alarm again. When you clear an alarm, you also remove it from the Alarms and Events table. However, Prime Infrastructure regenerates the alarm as soon as the associated events reoccur.

When working with alarms, events, and monitoring options, you may also want to configure notifications for specific events. Prime Infrastructure supports sending notifications either via email or SNMP traps. You can configure receivers under Administration > Settings > System Settings > Mail and Notification > Notification Destination. If you decide to configure notifications via email, you should also specify the Mail Server Configuration right above the previous menu.

The next step in configuring notifications are the Notification Policies themselves, either under Monitor > Monitoring Tools > Notification Policies or under Administration > Settings > System Settings > Alarms and Events.

A notification policy defines for which alarms, on which network device categories, Prime Infrastructure should send an email or SNMP trap to the configured destination email address or SNMP trap receiver. An example is sending an SNMP trap when a rogue AP event triggers the corresponding alarm.