This month I was working with a customer who was having a hard time understanding what AP MAC was being reported by Scrutinizer when using a Cisco Wireless LAN Controller. Honestly, I didn’t know everything that I needed to know about the subject so I decided to dig deeper and learn how our customers were using Cisco’s WLCs on their networks.
As you probably already know, a Wireless LAN Controller is used to manage lightweight access points in large quantities. I tend to see large-scale deployments of APs on academic campuses, although they’re not limited to these environments. The ability to manage hundreds of APs via the WLC helps admins out greatly, but Cisco stepped up the game by sending advanced traffic metadata via NetFlow.
Possible Request? Nope!
Flash back to Scrutinizer 17.8. Looking at the Flow View 
report, we could see that the WLC was sending out two elements related to MAC addresses. The first was staMacAddress, which represents the client in the conversation. The second MAC element is wtpMacAddress, which represents the MAC of the AP. BINGO! This was the first part of what we were looking for.
The end user needed a way to easily identify the AP by name and asked if we had a way to associate the AP MAC with a readable name. Luckily, our development team had just added the “associate a name to a MAC” feature in 17.8! The customer and I immediately started working on it.
What did they want to see with their AP MAC?
Sure, we all love seeing a bunch of MAC addresses every once in a while. But when you are trying to manage hundreds of APs, you need something easier to recognize like “Carolina West Residence Hall” instead of “3c:ce:73:1a:xx:xx.” Basically, the end user wanted easier-to-understand AP names in their reports.
As I mentioned before, Scrutinizer has a solution to help deal with this. To see the MAC to NAME management page, first navigate to the Admin Tab, click on Definitions, and then select MAC Addresses.
Here you will be able add a MAC address along with an associated label. Once the new MAC and label have been added, you should then see a new entry along with “User-defined” as its source entry.
You don’t have to do this manually, since the scrut_util engine automatically populates the MAC address at 1am every day. If an option template contains ”stamacaddress” and “username,” we put that info in the table when “scrut_util.exe –collect optionsummary” runs. That is once every hour.
To make a long story short, after some trial and error we found a few issues with the matching engine. We were also having some trouble finding the correct OID to match the wtpMACAddress with the AP name. The good news is that our dev team jumped on it and quickly fixed the issue. After a few tests, our reports were reflecting the correct names and with the SNMP update, we were automatically getting the correct AP names associated to the wtpMACAddress.
Why this was valuable?
After we resolved the issue of not seeing the correct name associated with the base MAC address, we were off and rolling. From that point it was easy to create a unique reporting environment with things like adding maps, adding specific reports, and applying monitors. Best of all, because it was their own unique Scrutinizer profile, this environment was specific to the wireless department’s needs. Because we were able to departmentalize their needs this way, the wireless team was able to piggyback on the budget of the security team and purchase Scrutinizer with enough licenses to cover their WLC’s.
In the end everyone was happy. So if one of your requirements is to get a better handle on the details inside your company’s wireless network traffic, but you don’t know where to start, why not evaluate Scrutinizer on your network?