Wireless Infrastructure Monitoring Capabilities in Netreo

This document outlines the wireless infrastructure capabilities present in BMC Helix Network Management.

Automatic Device Discovery

BMC Helix Network Management 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 BMC Helix Network Management 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 BMC Helix Network Management Cloud library.

Cisco-specific Considerations

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 BMC Helix Network Management via the auto-discovery process already described (or added manually by the end user). BMC Helix Network Management 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.

Meraki-specific Considerations

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, BMC Helix Network Management 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, BMC Helix Network Management 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 BMC Helix Network Management 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 BMC Helix Network Management as a feature request.

Licensing

When a BMC Helix Network Management 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 BMC Helix Network Management. 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 BMC Helix Network Management. 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 a BMC Helix Network Management license (as BMC Helix Network Management 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.

Availability Monitoring

BMC Helix Network Management 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.

Performance Trending

The second type of monitoring BMC Helix Network Management 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.

Cisco-specific Considerations

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 BMC Helix Network Management can query. This data is then stored as a history in BMC Helix Network Management's database. Should there be a desire to add/remove statistics, this can be done within a device's administrative interface in BMC Helix Network Management.

Meraki-specific Considerations

In BMC Helix Network Management, 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 BMC Helix Network Management due to inconsistencies in its reporting. For Meraki devices that are polled via local SNMP access, the statistics collected are: latency to/from BMC Helix Network Management, 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 BMC Helix Network Management Cloud libraries (provided they already exists), or can be created by the user via the BMC Helix Network Management 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 BMC Helix Network Management), that device can be monitored only for latency to/from BMC Helix Network Management, bandwidth for all network interfaces, and errors for all interfaces. In other words, interface polling only.

Log Monitoring

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 BMC Helix Network Management. In addition to the receiving of log-based data from wireless gear (in the form of syslog and SNMP trap information), BMC Helix Network Management can also process statistical data from those logs. Rules can be set up in BMC Helix Network Management 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 a BMC Helix Network Management device template, which would typically get applied to your controller devices (or your WAP devices provide they’re not licensed as “Lite”).

Configuration Management

The final area of monitoring BMC Helix Network Management is capable of for wireless gear is configuration management. For devices where a command line interface exists, BMC Helix Network Management 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.

Cisco-specific Considerations

Using a construct in BMC Helix Network Management known as a "command map" (currently only configurable by BMC Helix 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 BMC Helix Network Management with credentials for devices of that type, BMC Helix Network Management can begin to fetch configurations from those devices.

Reporting Capabilities

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 BMC Helix Network Management reporting features. Ad hoc reporting can be run from the UI on any of the variables being gathered by BMC Helix Network Management (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).

Conclusion

At this point, you should have a pretty good idea of how BMC Helix Network Management 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.