This document outlines the wireless infrastructure capabilities present in OmniCenter.
Automatic Device Discovery
OmniCenter has a robust auto-discovery engine built into it. The way this feature works is that a network scanner runs in the background and scans (on a subnet level) all devices present on a network. Where devices respond to a configured SNMP read-only string, the device is added to OmniCenter for monitoring and management.
Viewed in the context of wireless networking gear, this means that as new wireless controllers and access points become available on the network they will automatically be added. Where a device’s vendor can be detected, the proper device type will be assigned to the new device. Where type cannot be discerned, the device will be added as a “generic” device. (A more appropriate device type can be manually assigned later, if desired.)
At present, the wireless vendors detected out of the box are Cisco, Meraki and Aruba. If a vendor’s devices support the MIB-II SMNP standard, the type can be added via the Netreo Cloud library.
The way Cisco implements its wireless solution is that a controller device is added to a network and then access points (APs) are then associated to that controller. The APs themselves have very little configurability and do not support SNMP. So, instead, all statistics are retrieved from the controller.
A Cisco wireless LAN controller (WLC) would be added to OmniCenter via the auto-discovery process already described (or added manually by the end user). OmniCenter then periodically queries the controller and adds all the APs detected on that controller as devices. As the auto-discovery completes, the view in the UI looks similar to the screenshot below.
There is another scenario for wireless infrastructure monitoring where gear isn’t locally accessible via SNMP and there is no local controller device. Cisco’s Meraki technology subscribes to this architecture. The wireless controller for Meraki deployments is supplied as a cloud-hosted resource. Typically (although, not always) this cloud controller isn’t accessible via SNMP. Therefore, OmniCenter needs an alternative way to learn data from it. This is done via RESTful API access to the Meraki cloud controller. Overall functionality mimics the auto-discovery of local Cisco WLC devices. Except, in this case, OmniCenter hits the https address of the controller, learns the device list, and then uses this list to add the devices to be monitored and alerted on.
This SDK/API polling of Meraki is part of the core functionality of the OmniCenter monitoring engine. However, only Meraki and select other vendors are supported. Functionality cannot be manipulated by end-users, unlike other device types. Therefore, cloud monitoring of the wireless solutions of other vendors would have to be submitted to Netreo as a feature request.
When an OmniCenter license is installed, it is limited to a specific number of devices that can be managed. A “device” is the basic unit of licensing and monitoring in OmniCenter. It is any single, logical entity or operating system, such as a VM guest, VM host, single switch or stack of switches managed as a single entity.
The number of devices that a license is good for is broken down into two categories: Devices and Lite devices. “Devices” cover the majority of objects managed in OmniCenter. A “Lite” device is a ping-only device type that is only monitored for whether it is up or down. No other metrics are collected for Lite device types. Because of this, spaces for Lite devices in a license are significantly less expensive than for a regular device.
The concept of Lite devices was created primarily as a way of allowing the management of wireless access points (WAPs) without those devices each consuming a regular device space in an OmniCenter license (as OmniCenter typically gets WAP statistics from a wireless controller and doesn’t need to poll each WAP separately).
Cisco Aironet devices are automatically recognized as Lite devices. All other devices that you want to be Lite require that the “Ping Only” device type be assigned to it, and that there are Lite spaces available in the license.
OmniCenter has two primary types of “monitoring” it does for devices. The first is referred to as “availability monitoring.” This type of checking looks for the binary status of a given variable on a given device. The most common type of availability check is a “Ping” check to interrogate a device specifically for UP/DOWN status. However, if local access via SNMP to a device is supported, then any binary status the device makes available to a monitoring system can be tracked and alerted upon. Common examples here include network interface SNMP status and Cisco hardware status—which queries the FRU OIDs on Cisco gear for a Good/Failed state. Here’s a screenshot example of a monitored service list on a Cisco device.
The previously described “Lite” device does not have this capability, however. In order to do more than a simple ping check a device must have a non-“Ping Only” device type associated with it.
The second type of monitoring OmniCenter does for devices is performance trending of time-series statistics. This type of monitoring looks at data averages over time. The statistics that can be monitored depend entirely on what the vendor exposes via SNMP.
For Cisco WLC devices the primary time-series statistics available are CPU, memory, latency and bandwidth. There are others available, but these are what is configured by default.
The retrieval of these statistics are only possible because the vendor (in this case Cisco) exposes SNMP OIDs that OmniCenter can query. This data is then stored as a history in OmniCenter’s database. Should there be a desire to add/remove statistics, this can be done within a device’s administrative interface in OmniCenter.
In OmniCenter, performance trending capabilities are only available if there is local SNMP access to the Meraki device. Although performance data is available via the Meraki cloud portal, that data is not used as a source in OmniCenter due to inconsistencies in its reporting. For Meraki devices that are polled via local SNMP access, the statistics collected are: latency to/from OmniCenter, bandwidth for all network interfaces, and errors for all interfaces.
Other Device Type Considerations
Where specific performance trending information for other device types is necessary, a device type must be created that contains the desired SNMP OIDs. These device types can either be downloaded from the Netreo Cloud libraries (provided they already exists), or can be created by the user via the OmniCenter administrative interface. In a scenario where a vendor does not provide enhanced SNMP interrogation (leaving the device as an “Other (interface polling only)” type in OmniCenter), that device can be monitored only for latency to/from OmniCenter, bandwidth for all network interfaces, and errors for all interfaces. In other words, interface polling only.
So far, we’ve only talked about the pulling of diagnostic information from wireless gear. However, there is another subset of monitoring capabilities which relate to data being pushed into OmniCenter. In addition to the receiving of log-based data from wireless gear (in the form of syslog and SNMP trap information), OmniCenter can also process statistical data from those logs. Rules can be set up in OmniCenter to actively search logs for matches based on specific codes, severity levels or any regular expression. The statistics collected by these rules are stored as time-series historical data, and can trigger threshold or anomaly checks to send alerts for too many messages, too few, or if the current data is just different from what’s typical.
A sudden spike in log messages of a given type can indicate all kinds of issues, and now you can see the volume of messages in the context of time to really understand what’s going on in your environment. These messages are associated with the devices the logs originate from, so their performance histograms become available in the Device Dashboard for each device.
Logging rules are managed via the “Logging Rules” section of an OmniCenter device template, which would typically get applied to your controller devices (or your WAP devices provide they’re not licensed as “Lite”).
The final area of monitoring OmniCenter is capable of for wireless gear is configuration management. For devices where a command line interface exists, OmniCenter can log in to those devices, pull their configurations and check them for changes (generating alerts, if necessary), and even enforce compliance to a known good rule set. This is typically done nightly, but can be done more frequently if so desired. A requirement for this feature is that there be menu-free access to a CLI interactive terminal for the device.
Using a construct in OmniCenter known as a “command map” (currently only configurable by Netreo support engineers), a profile gets set up that allows the fetching of configuration information from a Cisco WLC.
Once a command map exists for a device type and the end user supplies OmniCenter with credentials for devices of that type, OmniCenter can begin to fetch configurations from those devices.
Provided that a wireless controller does respond to some kind of interrogation on status (either through availability or performance trending), it is then possible to take advantage of the already-present hooks into the OmniCenter reporting features. Ad hoc reporting can be run from the UI on any of the variables being gathered by OmniCenter (typically bandwidth, errors, latency and—in the case of Cisco WLC devices—CPU and memory). Once an ad hoc report has been created, it can either be saved as a “Favorite” (allowing repeated, easy access) or as a scheduled report (where it gets run and delivered on a repeating schedule).
At this point, you should have a pretty good idea of how OmniCenter can be used to monitor your wireless networking environment. But if you have any additional questions, feel free to post them in the comments section below or see the Contact Us page to get in touch with someone directly.