Can not pull AP inventory from Catalyst 3850 switches

[DFog14]

trafficstars

Expected Behavior

Cisco 3850s being used as wireless controller will return their AP inventory

Current Behavior

APs are only seen as neighbors

Possible Solution

SNMP Info should to run the AIRESPACE-WIRELESS-MIB against the 3850 switches, so that the wireless inventory can be pulled.

Context

Cisco allows for wireless controller modules on their 6500 and 3850 switches. As it currently stand, SNMP Info can see its connected APs as neighbors, but it can not query the wireless controller on the switch, for more detailed information, such as serial numbers.

Your Device

• Vendor: Cisco
• Device Model: WS-3850
• Snmpwalk output of .1.3.6.1.4.1.14179.2.2.1.1, specifically the bsnAP Sysoid

Your Environment

SNMP::Info version used: 3.64

[inphobia]

this could be an interesting one. airespace support is provided via snmp::info::airespace, but according to it's manual page "This class emulates bridge functionality for the wireless switch. This enables end station MAC addresses collection and correlation to the thin access point the end station is using for communication."

after having had a look at the source it seems to overwrite a lot of functions to make this work, functions which the layer3::c6500 needs. this might require a rework of how we interface with airespace devices or else add logic to the c6500 module to support it independant. either way i don't see an quick fix for this atm. perhaps someone with more experience on both airespace & ios can see a solution.

at any rate this will most likely take a lot of testing for regressions, so an snmp data dump will most likely be required (https://github.com/netdisco/snmp-info/wiki/Simulating-Agents#2-get-snmp-datadump) if that's an option for you.

[DFog14]

I've noticed that it's becoming more and more common in customer networks. I attempted a quick fix myself and realized that the c6500 module didn't want to play nicely with the airespace module, as you mentioned. Adding the logic independently seems like the only real solution at the moment, at least from my testing. If anyone has some guidance on how to go about implementing this, I'm more than happy to assist; hell, I'm still tinkering with it right now.

In regards to the snmp dump, I'll work on it getting one uploaded, but I'll almost assuredly have to alter names and ip addresses.

[inphobia]

in regards to the snmp data, if you consider it sensitive you can also provide it to the snmp::info devs in private where we won't share it without your permission.

given the complexity of this i really recommend using the snmprec method. converting snmpwalk output is non trivial in most case and had me chasing ghosts already.

since you say you're alrdy tinkering with it, if i would attempt this i would:

• copy the the snmp::info::airespace module to a new file & change it's package name (like to SNMP::Info::AirespaceTest or whatever).
• prefix all the functions it provides (so for example sub e_index i would rename to sub aire_e_index), this should make it not overwrite anything the c6500 module expects)
  • i would also remame os_ver() in %GLOBALS & fw_mac() in %FUNCTIONS.
  • make sure everything in your new module uses these new function names
• at this point you should be able to include this new module in layer3::c6500 without breaking anything which is alrdy working
• this is when the real work starts. for the renamed functions there are 2 outcomes:
  • they were not used by c6500 in the first place.
  • they would have been overwritten by the original airespace modules

for functions not used (i'm thinking of things like i_ssidbcast for example) you can can just call then then add these to c6500.

example:

*SNMP::Info::Layer3::C6500::i_ssidbast
= \&SNMP::Info::AirespaceTest::aire_i_ssidbcast;

for functions that were defined in both modules (like i_index) you'll need to figure out what it's doing to see if somehow their returned data might be merged. (you can modify the functions in AirespaceNew as well to prevent them from returning conflicting data)

now i just hope all of this made some sense 😀

major disclaimer: this is how i would try & get started. more seasoned devs might have more usefull options. also, even if the end result works perfectly we'll still need to figure out a clean way to get this imported.

we are happy to help you out if we can, either through this ticket, the snmp::info mailinglist or even better, irc: #netdisco on chat.freenode.net.

[DFog14]

Unfortunately, the snmprec method was not a viable option given the location and security of the server. I was able to get a snmpwalk(see attached)...though I should note all MACs have been zero-ed, ips have been changed and hostnames altered. The relevant MIB data is prefixed with .1.3.6.1.4.1.14179.2.2.1.1

I followed your device in creating a AirespaceTest module, but I think the overwriting of globals kept causing issues. Perl isn't my preferred language so I still have quite a bit to learn.

snmpwalk_3850.txt

[inphobia]

just an update to let you know this issue is not forgotten but given the complexity it's not on the top of my personal todo list. i'll try and have a decent look at it during the summer months when i'm less strapped for time.