Presenter: Paul Lysander, Technical Marketing Engineer, Cisco
“How many of you are not using PI 3.x?” –Paul; perhaps 10-20% put up their hands.
Morning after the customer Appreciation Event. Good turnout. 😁
Where does PI fit in the network?
- PI gets information from the network; it’s not the source of data
- Sources include: wireless LAN controller, CMX, ISE
Side note: PI 3.1 maintenance release 1 (MR1) is coming next week. When released, it will be the generally recommended release for customers to run.
Create Sites and Location Groups before adding devices to the inventory. These groups are used throughout PI. Eg: a Site can be used with a Virtual Domain to provide role-based access to devices in the environment (Admin1 can’t see Admin2’s devices; Admin1 only session Campus1 and SuperAdmin sees all). Device membership in a site can be done statically or by policy.
- Administration > Users > Virtual Domains (create and edit Virtual Domains)
- Administration > Users > Users, Roles & AAA (map users to a Domain)
- Discovery: templates can be discovered by pulling in the config (or parts thereof) from an already configured WLC
New feature in 3.1: Plug and Play for Wireless. Enables PnP onboarding of new APs onto the network.
- PnP Agent on the AP (which is there by default, nothing to install or activate) kicks. The process off when the AP comes onto the network
- Works together with APIC-EM because APIC-EM acts as the PnP Server; PnP Server sends the WLC IP addresses to the AP when the AP is initiating the PnP process. APIC-EM is required for Wireless PnP.
- When the AP gets the WLC addresses, it connects to the WLC and from there they do their magic.
Workflow for replacing APs:
- Example use-case was to upgrade AP models across the environment
- Tool in PI to bulk replace the old AP with the new one; replaces the AP on the maps, in Sites and Location Groups, and so on
- New/old AP mapping given to PI by uploading a CSV
Lightweight AP Templates:
- Templates can be pushed to a subset of APs by filtering on the WLC IP that the AP is associated with, the naming convention of the AP, and other fields (this is new and improved from 2.x)
- AP templates are incremental: if 3 of 25 parameters have changed, only 3 parameters are pushed; WLC templates are fully pushed every time
- Config Groups are groupings of Templates which can be applied to an AP as a single unit rather than applying multiple templates (which is just a lot of clicking in the GUI)
Map enhancements in 3.1:
- Import of site survey data/maps from Ekahau and AirMagnet; will create the map in PI
- Auto AP placement on a map; requires a structured naming convention of the APs; PI can place the AP on the correct campus/building/floor map by parsing the AP name and deriving the AP’s location
- Best practice for maps: try to limit the number of APs per floor to <= 100; also, manage alarms so there aren’t tons of outstanding alarms which have to be loaded when the map is loaded.
- New in PI 3.1
- Overlays alarms onto a street map; get a quick red/yellow/green status of the sites/locations in the network
- Services > App Visibility & Control > Site Visibility
- Does require adding geo coordinates when adding network devices to the inventory; if no geo coordinates entered, the map is not shown instead a table is shown
- AP health thresholds are set to Cisco best practice out of the box and can be tuned per Site (?) for custom thresshol (eg: interface utilization, client count, interference utilization)
Yes, PI can send SNMP traps northbound to a third-party NMS/receiver. Can filter which severity of alarms generate a trap so not every single little alarm triggers a northbound trap. SNMPv3 is supported.
- Customize the severity and enabled/disabled state of an alarm
- Auto clear alarms after a given duration
- Suppress an alarm for a given period of time before reporting it
- Policy based on percentage of APs that are down (only alarm when x% go down, not when 1 AP goes down)
- Policy based on duration of time that an AP is offline (only alarm after X minutes of downtime)
- Alarm policies can be build per Location/Site
- “Maintenance mode” when you know there will be maintenance happening and you don’t want alarms being reported; you must manually take devices out of maintenance mode, it’s not automatic
Q: Is there a ‘back in time’ feature for RRM or the heat maps?
- Short answer: no
- This has been requested in the past though
- Trick is figuring out how to store the large amounts of data that would have to be saved in order to enable this