How to succeed with wireless monitoring?

This procedure is unsupported Copied

Articles in the “Unsupported Community Documents” space are not supported by ITRS support.

Preamble Copied

This document intends to give a basic overview of the common problems with wireless networks, what problems may occur when administrating wireless solutions and what to monitor in wireless networks, followed by an example of how to set up baseline monitoring for a wireless access point.

Today wireless networks are a vital part of a business infrastructure side by side with physical networks and servers. As more devices are connected to the company network (laptops, mobile phones, tablets, etc.), and as the term Bring your own device (BYOD) gets more common, it becomes more important to keep track of the utilization of the wireless network to be able to work proactively to prevent failures and see bottlenecks in time.

This is a living document and will be updated or reorganized when more content is collected.

Terminology Copied

Client - A wireless device, such as a laptop or tablet, also referred to as a host

WAP - Wireless Access Point

Service - Representation of a point of measure in OP5 Monitor

Plugin - Small piece of software used by a Check Command to fetch data to a service

Check Command and check command args - The call for execution of a Plugin with certain parameters and settings

op5 Logserver Extension - Centralized Logserver used for collecting logs and making them searchable with filters, and to integrate with OP5 Monitor

Log filter - Condition-based rule to match against incoming logs

Implementation Copied

When implementing a new wireless network a site survey should be made to ensure the connectivity, signal blocking by walls, SNR, and Noise generated by surrounding sources in the environment. There is a lot of documentation out there regarding implementing wireless networks, and this article will not cover that.

Monitoring Copied

This section will go through some monitoring that can be easily implemented on a wireless access point to ensure its operational status. There are a lot of measurements that can be done and this text will only cover the baseline with the following parameters:

• Ping
• Interface status, errors, and traffic (Physical and radio)
• Connected Clients
• Failed Authentications

The most basic is of course to check if the device is online and powered on; for that we use a simple ping check. In OP5 Monitor this is the first check that is automatically added to every host. This document will not go through this step; please refer to the check_ping plugin documentation.

Interface Monitoring Copied

Monitoring the interfaces is one of the most basic steps to check on a network device. This gives you the possibility to measure and notify on spikes in traffic. Monitoring the usage on an interface in general makes it possible to do capacity planning before the usage hits the roof. We will also monitor unusual amounts of errors/discards, and check if an interface is up on both the physical interfaces and, since Cisco creates a virtual interface for VLANs, we can also monitor interface statistics per VLAN interface.

So, let’s add some interface monitoring.

Use the search box to find your device, and click “Go”.

When you have entered the configuration page for the host, use the “Related items” menu on your right to “Scan for SNMP interfaces”.

This will give you a menu where you enter your SNMP community and SNMP version. Select 2c if available on the device. Your selected host is already defined in the “Hosts to scan” list.

Hit the “Scan hosts” button to do an interface scan of the device.

This will give you a list of active interfaces on that device as shown below, both physical interfaces and per VLAN, if using a Cisco device.

Hit “Add selected services” when you have chosen what interfaces to monitor:

This will give you information about the number of added services:

Hit the floppy icon in the top right corner to save your configuration. This is the first step of a configuration save which is a sanity check of the configuration you have entered. This will give a summary with changelog on your configuration changes.

Select “Yes, save” in this next dialogue.

Now, use the search box in the top right corner to find your host with your newly added services.

Now you have interface monitoring on all the interfaces on your AP.

Connected Clients Copied

Measuring the number of connected clients can also be a way to be proactive and be able to react before the number of clients hit the max number of connected clients on your device. The following plugin measures both the 2.4 GHz and the 5 GHz band.

This data is also possible to fetch via SNMP via specific OIDs. The difference is that this plugin does a calculation and gives a total summary for both 2.4 and 5 GHz bands.

In this example, we use a Cisco Aironet 1040 which has a maximum number of connected clients of 25, so we want to give a warning if we get close to this value.

The plugin check_cisco_aironet_clients used in this example can be found here. It is created in Perl and should run on any Linux distribution with the right dependencies installed, as listed below:

• perl-Net-MAC
• perl-Net-Telnet (Dependency of perl-Net-Telnet-Cisco)
• perl-Net-Telnet-Cisco

To install these on op5 Appliance 6 or CentOS 6 you can download the dependencies from here: cisco-aironet-dependencies.tar.gz

Now when you have all the dependencies on your local computer they must be moved to your op5 Monitor server. Once these files are on your op5 Monitor server you need to move the plugin file to the correct directory and install the dependencies.

Log in via SSH as root and issue the following commands to do this:

tar xvzf cisco-aironet-dependencies.tar.gz
rpm -ivh perl-Net-*
mv check_cisco_aironet_clients.pl /opt/plugins/custom
chmod +x /opt/plugins/custom/check_cisco_aironet_clients.pl

Now that the plugin is in place and the dependencies are installed properly, let’s add a check to op5 Monitor to give some data from this check with some nice graphs, and thresholds for warning and critical.

Go to the configuration page in the menu, select “Commands”, and copy-paste the following:

command_name:

 check_cisco_aironet_clients

check_command:

 $USER1$/custom/check_cisco_aironet_clients.pl -H $HOSTADDRESS$ -U $ARG1$ -P $ARG2$ -C -w $ARG3$ -c $ARG4$

Press “Submit” and hit the floppy in the top right corner, and “Yes, save”.

Now, let’s put our newly created check command to use. Mark the search box as earlier to find your host, then hit the wrench to get to the configuration interface.

Press “Services for host” to get to the interface for services.

Fill in the following values:

• service_description: Connected Clients
• check_command: check_cisco_aironet_clients
• check_command_args: user!password!warn!crit
  • This should be your username, password, warning, and critical thresholds. As mentioned before the max number of clients for this device is 25 simultaneous clients. You should change this to what your device supports.

Press “Submit”, the floppy in the top right corner, and “Yes, save”.

Now, back to the status page for the host via the search box, and you will have something similar to this to display after some performance data has been gathered.

Log Monitoring Copied

A great source of information is the system log of a device, since I have not found any usable counter for SNMP to fetch the data from failed authentication attempts, so I will get this from the log of the device, which is forwarded to op5 Logserver for easy monitoring.

This section will not cover the configuration of the WAP. Some of the related configurations of op5 Logserver are listed below. For full documentation on op5 Logserver Extension please refer to OP5 Monitor Documentation.

When you have configured your WAP to forward its logs and configured your op5 Logserver to communicate with op5 Monitor:

The important settings to set here to perform this task are:

• Rotate database after x hours? This setting is important because it reflects how long back in time you want to search, both in the Logserver GUI, and with your checks that will be used in op5 Monitor.

• The monitor host. The address or IP address of op5 Monitor

• Use Monitor 5. The legacy setting needs to be checked.

• Host information page: /ninja/index.php/status/service/[host]. This is where the status page of hosts in op5 is located, needed to make a smooth integration between Logserver and Monitor. Host links in Logserver are clickable and redirect you to op5 Monitor.

To make this connection between op5 Monitor and Logserver we need a couple of filters to use in the check against Logserver.

To import the filters, go to “Settings -> import filter”. Select your filter to be imported and press “Import”. Be sure that the filter is marked as “Global”. If not, this filter will only be available for the user who imported it.

To connect your op5 Monitor to this newly imported Logserver filter we need to have a user in Logserver to connect with. This user needs to be in the “Filter Administrators” group to have sufficient privileges to fetch this data from the filter.

Go to “Settings -> Users & Groups”. Create a new user as shown below:

Now when the user is created and filters are imported, it is time to make the connection between Monitor and Logserver.

Go back to the configuration page of your host as described earlier: “Search -> Configuration Wrench -> Services for host”.

This will give you an empty configuration for a new service, and here we will make the connection to the logserver filter we imported earlier.

Fill in the following parameters:

• service_description: Failed Logins on Access Point 01
• check_command: check_op5_logserver_filter
• check_command_args: auth-fail-ap01!3600!logserver.local!monitor!monitor!https://logserver.local!3!5

Explanation of check_command_args:

• ! is the separator between options in check_command_args
• auth-fail-ap01 is the filter name that we want to call in the Logserver
• 3600 is the time period we want to check for matching of this filter in minutes. This is relevant to the “Rotate database after ? hours” option set in the Logserver as mentioned earlier.
• monitor!monitor is the username and password we configured earlier in the Logserver
• https://logserver.local is the URL of the Logserver host to make clickable links in the Service we are creating
• 3!5 are the warning and critical thresholds for the service. How many matches in the given time period we are checking should return a “Warning” or a “Critical” state.

All this makes more sense in the “Syntax Help” button which explains the parameters that are activated. These values are just theoretical and may need to be modified depending on your environment’s normal value and what is acceptable.

When the above settings are configured, press “Submit” -> the “floppy” -> and “Yes, save”.

Navigate to your host to see the status of your new check.

Related downloads Copied

• cisco-aironet-dependencies.tar.gz