Wireless Infrastructure Monitoring Capabilities in Netreo

This document outlines the wireless infrastructure capabilities present in Netreo.

Automatic Device Discovery

Netreo 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 Netreo 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.

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

The “Overview” tab of the Device Dashboard for a Cisco Aironet device showing its list of wireless access points.

 

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, Netreo 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, Netreo 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 Netreo 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.

A Meraki cloud controller being added to Netreo for monitoring.

 

Licensing

When a Netreo 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 Netreo. 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 Netreo. 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 Netreo license (as Netreo 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

Netreo 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 “Services” tab of a device’s Device Dashboard.

 

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 Netreo 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 “Performance” tab of a Device Dashboard showing performance statistics for that device.

 

The retrieval of these statistics are only possible because the vendor (in this case Cisco) exposes SNMP OIDs that Netreo can query. This data is then stored as a history in Netreo's database. Should there be a desire to add/remove statistics, this can be done within a device's administrative interface in Netreo.

Editing a poller in a device type in Netreo.

 

Meraki-specific Considerations

In Netreo, 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 Netreo due to inconsistencies in its reporting. For Meraki devices that are polled via local SNMP access, the statistics collected are: latency to/from Netreo, 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 Netreo 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 Netreo), that device can be monitored only for latency to/from Netreo, 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 Netreo. In addition to the receiving of log-based data from wireless gear (in the form of syslog and SNMP trap information), Netreo can also process statistical data from those logs. Rules can be set up in Netreo 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 graph showing log rule matches over time.

 

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 Netreo device template, which would typically get applied to your controller devices (or your WAP devices provide they’re not licensed as “Lite”).

Setting up a log rule in a Netreo device template.

 

Configuration Management

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

The command map for a Cisco wireless LAN controller.

 

Once a command map exists for a device type and the end user supplies Netreo with credentials for devices of that type, Netreo can begin to fetch configurations from those devices.

The configuration management page for a device.

 

Viewing the most recently downloaded configuration for the above device.

 

 

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

A configured report from Netreo containing CPU and bandwidth utilization data.

 

Conclusion

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