This document aims to outline a way to extract client association data from a Cisco WLC so that it can be referenced later. My organization has a business requirement to track all wireless users. We use the techniques outlined in this document to take a "snap-shot" of our wireless clients associated with a Cisco WLC every 5 minutes and import that data into Splunk, where we can index and search through it any time we want.
This document will cover some basics needed to successfully extract connected client data from a Cisco WLC via SNMP. Although this feat has probably been done before, I was able to find little documentation on how to extract this specific data and use it for historical purposes. This document will provide MIB information to key OIDs of value, a bash scripting example, and lessons learned.
Cisco provides excellent SNMP MIB documentation. For those who don't know what a MIB is, it stands for Management Information Base. A MIB is like a road map for SNMP enabled systems. The MIB allows you to identify and navigate to key data points that you wish to query. Without a MIB for a corresponding piece of equipment, you will be making arbitrary requests for seemingly random data-points.
This tool allows you to step through an SNMP tree and locate the OID you are looking for, so you can query the data you want. In this tutorial we will be using the SNMP tool suite for Linux and the snmpget and snmpwalk commands specifically.
The OIDS below will be what we focus on.
Client MAC Address List:
snmpwalk -v 2c -O x -c public 10.1.1.252 126.96.36.199.4.1.14188.8.131.52.1.1
Client IP Address List:
snmpwalk -v 2c -c public 10.1.1.252 184.108.40.206.4.1.14220.127.116.11.1.2
Client Username List:
snmpwalk -v 2c -c public 10.1.1.252 18.104.22.168.4.1.1422.214.171.124.1.3
AP MAC Address List:
snmpwalk -v 2c -O x -c public 10.1.1.1.252 126.96.36.199.4.1.14188.8.131.52.1.4
Client SSID List:
snmpwalk -v 2c -c public 10.1.1.252 184.108.40.206.4.1.14220.127.116.11.1.7
SNMPv2-SMI::enterprises.1418.104.22.168.22.214.171.124.126.96.36.199 = Hex-STRING: FC C7 34 DE 0B 8C
SNMPv2-SMI::enterprises.14188.8.131.52.184.108.40.206.220.127.116.11 = Hex-STRING: 84 78 AC B8 2F 90
Using the above OIDs and command examples we can collect the data we want.
By querying 18.104.22.168.4.1.1422.214.171.124.1.1 we get a complete list of client MAC addresses currently associated with the WLC. You may have noticed in the example output, that the different pieces of information all contain the same unique sequence on the end of the query. (Ex.
252.199.52.222.11.140) This will allow us to query a specific user's attributes. Now that we know the basics of SNMP and know where the data is, we can start scripting to put everything into a more readable format.
(Please excuse my scripting. I'm no coder. This is for practical application and demonstration purposes only.)
The script example below is a bash script that was designed to be cron'd on a Linux host. The output of the script looks like this:
MAC address entries need to be queried with the SNMP option -O x so that they only return results in HEX. I had several cases where a client was improperly displaying it's MAC address in ASCII and it contained line breaks that was messing everything up. I don't know why or how the controller let that happen, but it was the controller that saved the data into that SNMP value. The solution was to ensure that SNMP get and walks only returned HEX values for those querys.
By default SNMP query results have spaces and by default bash arrays interpret spaces on array input as field separators. Modifying IFS will fix this for you, as noted in the script above.
In order to have a working set of data, you need to ensure all SNMP queries contain the same number of results. If they do not match, you are querying user data for users who may no-longer be associated. To combat this, I threw the whole get sequence into a loop. It runs fast enough to eventually get the data I need. I am sure there are better ways, but this works fine for now.
Sometimes users show up with a 0.0.0.0 IP. I assumed these users are in a limbo state waiting to be fully associated or until their PEAP authentication passed. In any case, they aren't realistically on my network so I didn't care and discarded the results for their connections. I interpreted this data as the controller creating a placeholder for them until they are associated.
With the data you can collect using Cisco's MIBs and SNMP there is no limit to what information your gear can show you. My organization has used it with great success to meet business requirements. Being able to historically see who was on your wireless network at any time will give you a huge advantage. We can turn around DMCA notices, track users, identify usage peaks and wireless trends at various facilities, and to a certain degree, identify coverage issues. We also have a similar script to collect this same data from Meru systems as well. Although this guide may not be perfect and the scripting could be improved, I felt it necessary to share.
Hello? I have questions about RV320 access rules.1. What is setting "Source interface"?Is it interface that access rule implemented? Or is it cohered with setting "Source IP"?2. I set Action=Deny, Service=All(1-655353), Log=No log, Source interface=WAN1, ...
how to connect this router (the one at the top) to the 3 switches at the bottom, these are 2 different networks with 2 different subnet masks. I did the interface encapsulation but it doesn't send packets from any pc in Sales & Marketing Network (the ...
model: n9k-c93180yc-fxNetwork Management
I try configuration migrate from nexus 3548 to nexus c93180yc-fx
when I copy and paste police map but, the following error message was displayed.
(config-pmap)# class copp-...
Can't enable boost license config)#platform hardware throughput level boost not available. FLM240302GF_20220520020540.lic was installed and Version 16.8.3
Fuji I thought was the requirement, what am I missing.
Index 11 Fea...