New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


How can I monitor a Cisco WLC deployment with PRTG?

Votes:

0

Your Vote:

Up

Down

I have a Cisco Wireless LAN which is managed by a WLC appliance.

Is there any way to obtain meaningful information from the appliance using PRTG? Are there built-in sensors I can use?

This device's operation is very sensitive for my organization and we want to have additional monitoring so that we are alerted as soon as anything goes wrong.

What are my options? I've attempted to use the MIB but had a hard time importing it and deploying any sensors.

cisco cisco-wlc device-template paetemplate prtg snmp system-health wlc

Created on Aug 21, 2017 12:10:23 PM by  Luciano Lingnau [Paessler Support]

Last change on Aug 22, 2017 9:20:42 AM by  Luciano Lingnau [Paessler Support]



18 Replies

Accepted Answer

Votes:

1

Your Vote:

Up

Down

This article applies to PRTG Network Monitor 16.3.25 or later

Additional Sensors for Cisco WLC Controllers

While PRTG provides a couple of sensors that work with the WLC controller by default, for example the SNMP Traffic sensor and the SNMP System Uptime sensor, but you may still be interested in more detailed sensors.

Adding Custom Sensors to the WLC via Auto-Discovery

You can use the device template that we provide below to automatically create custom sensors with the PRTG auto-discovery.

The metrics that are available can vary. The sensors can monitor the following if the data is available:

  • Access Point
    • Operation Status (Associated/Disassociating/Downloading)
    • Admin Status (on/off)
  • Controller Statistics
    • Connected APs (count)
    • Connected Clients (count)
    • Access Point Failed Assoc. Count (count)
  • SSID Statistics
    • Connected Stations (count)
    • Admin Status (on/off)
    • Broadcast SSID (on/off)

The device template creates the available and compatible sensors based on the data at hand. The sensors implement default alerts whenever possible, but you can still fine-tune most channels by defining additional limits in the sensor channels settings or modifying the lookups included by default.

Requirements

  • PRTG Network Monitor 16.3.25 or later
  • Because the device template relies on the auto-discovery process, the device you want to monitor needs to be reachable via PING.
  • SNMP must be enabled and the device must support the AIRESPACE-WIRELESS-MIB and CISCO-LWAPP-SYS-MIB. The documentation to enable SNMP is available on:
  • The device template has been tested with the following devices so far:
    • Cisco 1815 Mobility Express
    • Cisco 2504 Wireless Controller
    • Cisco 5508 Wireless Controller
    • Cisco 5520 Wireless Controller
    • Cisco Flex 7500 Series Wireless Controller (iOS 8.3.143.0)

If it works for you with a different model, please let us know!

Known Issues and Limitations

  • To monitor access points, the bsnAPSerialNumber is used for uniquely identifying and tracking individual access points. If an access point is renamed, the sensor's name will not be updated automatically. Either change it manually or delete the sensor and re-run the discovery.
  • When more SSIDs are created or more APs are connected, re-run the discovery to monitor these. You can also use the Auto-Discovery schedule for this.
  • If the SSID is renamed, the corresponding sensor will fail. Either update the name in the sensor's settings or delete the sensor and run a new auto-discovery with the template.
  • PRTG shows the alerts as reported by the monitored device via SNMP using lookups. If the status is not reported correctly via SNMP, PRTG cannot detect any issues. For additional alerts, please set up limits for additional channels.
  • This device template was created based on data collected from other customers, so we cannot guarantee that the sensors described above will work on your systems. Use these components at your own risk. Please test and validate the sensors in your environment after deploying them.

Deployment and Usage

  1. Download the required zip archive here.
  2. Extract the archive to your PRTG program directory. By default, this is %Program Files (x86)%\PRTG Network Monitor\.
  3. In PRTG, restart the core server: open Setup | System Administration | Administrative Tools | Restart Core Server and click Go!. This ensures that the MIB and lookups are loaded before you run the auto-discovery.
  4. Create a new device in PRTG with the address (IP or FQDN) of the device that you want to monitor and configure the SNMP credentials accordingly.
  5. Right-click your new device, select Run Auto Discovery with Template, browse for wlc and select the Custom Cisco WLC Access Point Status v0.2 and Custom Cisco WLC SSID Statistics v0.2 templates from the list.
    Note: Using the auto-discovery with a dedicated device template is convenient here because it automates the creation of the custom sensors in an organized fashion.
  6. The sensors are deployed after a couple of seconds.
  7. You can adjust the channel limits or lookups to your needs later.

Result

The resulting sensors look like this:

Sensor's Overview

AP Sensor's Overview

Click for full-screen view

SSID Sensor's Overview

Click for full-screen view

AP Sensor's Overview

Click for full-screen view

Device's Overview

Device's Overview

Click for full-screen view

No sensors deployed? :(
Please read ahead for troubleshooting.


Troubleshooting

Have any issues? Please don't hesitate to contact us by replying to this post or via a support ticket. Please make sure to mention this KB post. Please read ahead for troubleshooting steps that you can take in advance.

Auto-Discovery Log

Your auto-discovery log tells you a lot about what went wrong during the sensor's deployment. You can troubleshoot the auto-discovery by inspecting the auto-discovery log. If you get entries like the one below (NOT FOUND), it means that the required protocol or Object Identifier (OID) is not available and the sensors can't be deployed.

[...]
21.08.2017 09:17:17: Template Loaded; Device ID: 22848; Name: Custom Cisco WLC SSID Statistics v0.2
21.08.2017 09:17:18: Template Check; Device ID: 22848; Check ID: ping; FOUND
21.08.2017 09:17:19: Template Check; Device ID: 22848; Check ID: snmp; FOUND
21.08.2017 09:17:20: Template Check; Device ID: 22848; Check ID: snmp_bsnDot11EssTable; NOT FOUND
[...]

In the example above, some sensors were skipped because the device did not respond to the snmp_bsnDot11EssTable check. This means that this data is probably not available on your device. You can track this data by looking for the name after snmp_. In this case, a search for bsnDot11EssTable will tell you what OID from what MIB is missing.

You can also use this log to identify if the discovery was interrupted because the device did not respond to PING or to a basic SNMP check.

SNMP Data

If the discovery log is not sufficient, you can review the SNMP data directly from your device. To do so, save the text below (in the white box) as .txt and use it with the Scan Script option in our SNMP Tester. This will allow you to review which SNMP queries succeed and which do not deliver any data. Please have this information at hand when contacting our support team.

--------
Walk Default
--------
hrSystemUptime
walk=1.3.6.1.2.1.25.1.1
--------
MIB-2 System
walk=1.3.6.1.2.1.1
--------
Sensor Specific Queries
----
clsSysInfo
walk=1.3.6.1.4.1.9.9.618.1.8
---
bsnAPTable
walk=1.3.6.1.4.1.14179.2.2.1
---
bsnDot11EssTable
walk=1.3.6.1.4.1.14179.2.1.1
---

Version History

VersionDescription
0.1Test Version
0.2Initial Public release



Best Regards,
Luciano Lingnau [Paessler Support]

Created on Aug 21, 2017 12:11:12 PM by  Luciano Lingnau [Paessler Support]

Last change on Sep 24, 2018 10:22:22 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hi Luciano and Brandy,

First of all, thank you both for posting this! I've tried a few times over the last few years to get useful information out of or WLC's finally!

The template worked well for me, and I was able to get a comprehensive list of all of our AP's. I'm wondering how difficult it would be to get collect the client count for each AP? The ability to graph this over time would aid in capacity planning... a lot!

I've tried getting the client count with this oid "OID=1.3.6.1.4.1.14179.2.2.2.1.15" using a bash script, but your help would be appreciated as I was never able to conveniently correlate this with the AP name.

Look forward to hearing from you, and keep up the good work!

Curt

Created on Oct 18, 2017 9:51:33 PM by  curtisbowden (0)



Votes:

0

Your Vote:

Up

Down

Hello Curt,
thank you very much for the kind feedback.

As for the "client count", that's a bit complicated due to the way that the data is made available by the AIRESPACE-WIRELESS-MIB. This metric is part of the bsnAPIfTable, which is a multi-indexed table:

bsnAPIfEntry OBJECT-TYPE
    SYNTAX BsnAPIfEntry
    MAX-ACCESS not-accessible
    STATUS current
    DESCRIPTION
        "An entry in bsnAPIfTable."
    INDEX           {
                        bsnAPDot3MacAddress,
                        bsnAPIfSlotId
                    } 
    ::= { bsnAPIfTable 1 }

For example, this is how the data for one access point would look like:

1.3.6.1.4.1.14179.2.2.2.1.15.0.142.115.69.70.12.0 = "2" [ASN_COUNTER]
1.3.6.1.4.1.14179.2.2.2.1.15.0.142.115.69.70.12.1 = "6" [ASN_COUNTER]

To break-down this OID (for the first value from the list above) :

1.3.6.1.4.1.14179.2.2.2.1.15.0.142.115.69.70.12.0The metric (bsnApIfNoOfUsers)
1.3.6.1.4.1.14179.2.2.2.1.15.0.142.115.69.70.12.0The Mac Address of the Access Point, available in the bsnAPTable. The name is also available in this table under 1.3.6.1.4.1.14179.2.2.1.1.3)
1.3.6.1.4.1.14179.2.2.2.1.15.0.142.115.69.70.12.0The slot of the interface (for AP's that have more than one WLAN interface

This makes it very difficult to provide sensors with adequate naming/metrics using just the auto-discovery. While the SNMP Custom Table sensor is very powerful, it is not this flexible yet. For now only a built-in sensor would be able of handling this correctly, and unfortunately we don't have any WLC sensors on the roadmap for now.

Depending on the number of access points that you have, you could deploy multiple SNMP Custom Table sensors (for many APs at once) or any number of SNMP Custom Advanced sensors to cover the relevant AP's, but this will require some elbow grease and patience to have everything looking/named the way you want. Since the "indexing" of the table uses the Mac Address and "slot id" (which should be fairly persistent) once deployed the sensors should be reliable, even without index change support (as there's no identification column in the table).

Lastly, I want to point out that the SNMP implementation from the MIB is fairly good, the limiting factor here are the Custom Table Sensor's capabilities. While I understand that my reply doesn't really provide a solution to the issue/question, I hope that it at least makes clearer why we're not able to provide this (at least not at this point in time).

Edit/update: You've mentioned that you're working on doing this with a Bash/Script. I encourage you to locate the mac address after the walk of that entry, leave out the trailing digit (the slot number) and then find the respective AP's Name in the appropriate table, that way you could have a single sensor displaying the summarized (for all interfaces) for every single AP in one single sensor. If you get to a working please share it here on the KB, I'm sure you're not the only one looking to achieve this. :)

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Oct 23, 2017 8:21:56 AM by  Luciano Lingnau [Paessler Support]

Last change on Oct 23, 2017 8:27:00 AM by  Luciano Lingnau [Paessler Support]



Votes:

1

Your Vote:

Up

Down

Works also great with WLC 2504 series

Thanx

Created on Oct 24, 2017 6:43:47 PM by  wayne7215 (40)



Votes:

1

Your Vote:

Up

Down

Works also great with WLC 5520 Wireless Controller!

Thanx!

Created on Nov 14, 2017 10:49:56 AM by  Sebastian5000 (10)



Votes:

0

Your Vote:

Up

Down

Hello Support,

I have applied this solution to monitor access points from a Cisco WLC deployment. It works very good for us.

Is it possible to add some more information in the sensors of the Access Points? I would like to monitor the Radio description and Radio Status per Access Points.

The MIB for this is CISCO-LWAPP-AP-MIB

Group: clap dot11if: #[1.3.6.1.4.1.9.9.513.1.1.1.1.1]
Name: clap dot11if admin status: #[1.3.6.1.4.1.9.9.513.1.2.1.1.1]
OID: 1.3.6.1.4.1.9.9.513.1.2.1.1.14
This object represents the AP's interface admin status. A value of 'true' indicates admin state as Up. A value of 'false' indicates admin state as Down.
Group: clap dot11if: #[1.3.6.1.4.1.9.9.513.1.1.1.1.1]
Name: clap dot11if desc: #[1.3.6.1.4.1.9.9.513.1.2.1.1.1]
OID: 1.3.6.1.4.1.9.9.513.1.2.1.1.21
This object represents the description of this interface

This MIB works for the Cisco 5508 Wireless Controller.

Kind regards, Peter Meijer

Created on Nov 22, 2017 3:55:27 PM by  pmeijer (10) 1

Last change on Nov 23, 2017 8:19:45 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello Peter,
thank you very much for your feedback.

Unfortunately that's not trivial, basically due to the same constrains/limitations as described here.

This is the SNMP Data:

cLApDot11IfEntry OBJECT-TYPE
    SYNTAX          CLApDot11IfEntry
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION
        "An entry in this table represents the 802.11
        functional parameters of the dot11 interface of
        an AP that has joined the controller.

        Entries are added when the APs associate to this
        controller and deleted when they lose their
        association."
    INDEX           {
                        cLApSysMacAddress,
                        cLApDot11IfSlotId
                    } 
    ::= { cLApDot11IfTable 1 }

This means that we're not able to offer any short-term native alternatives for that.

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Nov 23, 2017 8:27:17 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Luciano,

Can you expand on how you derive the OID value from the MAC address for use as an index identifier?

In your example above, you were able to convert the hexadecimal MAC address into: 0.142.115.69.70.12. I'm looking for confirmation on how that is accomplished. Did you use a standard Hex base 16 to decimal base 10 conversion foreach "octect" of the mac address? Thus making the following true?

00 = 0 8E = 142 73 = 115 45 = 69 46 = 70 0C = 12

Created on Dec 27, 2017 3:29:18 PM by  Paul8080 (0)



Votes:

0

Your Vote:

Up

Down

Dear Paul,

hexadecimal SNMP values cannot be usefully converted with PRTG, especially if the value is built-up from multiple components.

Created on Dec 28, 2017 4:06:31 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hi, I need some help.

I would like to know which SNMP trap controls are activated on your WLC controller in order to get the sensors showing on your blog working please.?

Many Thanks

Created on Jan 19, 2018 8:27:33 PM by  eliturmel (0)



Votes:

0

Your Vote:

Up

Down

Hello eliturmel,
thank you for your reply.

The template and sensors work with SNMP GET requests, it does not rely on trap messages. I did however expand the Requirements section of the post with two links related to the SNMP Setup for the controller.

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Jan 23, 2018 6:45:33 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

@Paul8080,
I had missed your earlier reply, sorry for that.

I have no documentation to support my claim/belief, but I've seen this sort of implementation before and it "makes sense" to me. But I'm unable to confirm for certain what precise conversion is done but would also tip at hex base 16 to decimal base 10 as you've suggested.

Since it will be hard to come by documentation that confirms this I encourage you to perform an snmp walk on an active WLC and confirm it by looking at the actual data. If the conversion checks out with hex base 16 to decimal then it's probably right.

If you do find any documentation (or your tests confirm this), please link it in a reply to this post, in case anyone else is interested. :)

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Jan 23, 2018 6:54:50 AM by  Luciano Lingnau [Paessler Support]



Votes:

1

Your Vote:

Up

Down

Confirmed working with Cisco 1815 Mobility Express as well. Many thanks for this!

Created on Feb 16, 2018 10:21:17 AM by  Wouter Hindriks (10) 1



Votes:

1

Your Vote:

Up

Down

This also works for the Cisco 7500 Series WLAN Controller with IOS version 8.3.143.0. We are monitoring 1175 AccessPoints with this template.

Created on Sep 12, 2018 7:50:07 AM by  pmeijer (10) 1

Last change on Sep 12, 2018 11:45:22 AM by  pmeijer (10) 1



Votes:

0

Your Vote:

Up

Down

Hello Support,

I am using this template for a while now and it works good for the Cisco WLC 5520 with version 8.2.167.6 but not when I apply this to Cisco WLC 5520 with version 8.5.135.0. The accesspoints and SSID are not showing after running the autodiscover with the templates.

Has anybody else got experience with this and maybe a solution for this?

Kind regards, Peter Meijer

Created on Mar 28, 2019 8:20:16 AM by  pmeijer (10) 1



Votes:

0

Your Vote:

Up

Down

Peter,

We would need to get SNMP Walks from the device running that code to see how the OID structure has changed, and compare that to the script.

If you want to open a support ticket, we can work with you on this.

Benjamin Day
Paessler Support

Created on Mar 28, 2019 7:54:09 PM by  Benjamin Day [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Has anyone been able to get netflow working with their Cisco WLC? I've been at this all day with no luck.

Created on Mar 28, 2019 10:50:41 PM by  tnunno (1) 1



Votes:

0

Your Vote:

Up

Down

Tnunno,

Have you been able to receive flows with the Netflow tester on your PRTG server or the probe you want them to go to?

Netflow Tester

Let me know if the tester is able to get the flows or not.

Benjamin Day
Paessler Support

Created on Mar 29, 2019 4:44:38 PM by  Benjamin Day [Paessler Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.