Solarwinds is not flexible for monitoring wireless AP's anyone aware of solarwinds roadmap in wireless ???
rajasekar What exactly do you mean and/or what are you looking to do? Different modules have different things they can do with cisco wireless gear in various forms.
I need to see the clients connected in AP in a dynamic method. If the client moving to different Ap connection in a live status i need to see ?
All the KPIS of Wireless need to vary dynamically like Singnal strength & Signal nosie ratio everything ?
I need to schedule unmange to AP ?
I need to White list client in that AP ?
Firmware upgradation in AP ?
Bulk Configuration push to AP ?
Dependency set to AP ?
Above are the few important features am looking in solarwinds. Right now we are using different tools to perform all these features. Only for monitoring the AP status we are using solarinwinds because of all network device monitoring in solarwinds.
SNR would be nice, but I think that since it isn't always available in SNMP the Orion devs opted not to collect it, since it would be blank for a significant portion of devices, not even all Cisco wireless systems support it. You could just add a custom UNDP for it on your WLC's for your use case.
Signal strength is collected and bitrate and total transfers and most of the other common ones, when the hardware makes it available.
To your comment about all those wireless features you wish NPM had, it's good to ask because that lets them know there is a demand, but I also try not to expect anything to immediately happen around any of my requests unless I see a ton of upvotes for it.
I think this basically comes down to ROI for them developing that feature set.
Solarwinds tries to be intentionally cross vendor. Doesn't always work out that way 100%, but they have reasonable level of compatibility with a pretty broad range of vendors.
When they added in wireless monitoring as a free feature of NPM I think they figured they could develop something that was generally useful enough for basic alerting and monitoring for many use cases, without sinking a lot of dev time into it and I think they accomplished that. Could still use a few tweaks but its alright, especially when you figure it was targeted toward the wifi market of 2015/2016 when they developed it, so they hadn't thought of some of the things that make newer controllers weird in Orion.
They will probably continue to throw in little bits here and there as demand builds up, but at the end of the day if it is going to require a really significant amount of dev effort then they would probably end up creating an entire new module around advanced wireless capabilities, similar to how you get basic virtualization monitoring with core Orion, but if you need more details and metrics you end up buying VMAN to expand that.
The feature list you gave is basically asking for Orion to have feature parity with Prime, the in house tool built by Cisco for Cisco.
The tricky part then becomes a question of can Solarwinds cost effectively develop a tool that can be as good at multi vendor stuff as each vendor is at their own wireless platform? I think that's a pretty tough sell because wireless is an extremely proprietary arena. If SWI builds something to have feature parity with Prime, they are more than likely going to have to do the same things for Aruba, Ruckus, Meraki, etc. For each of those vendors there will be a lot of custom work because of how fragmented and inconsistent that market is. I basically can't reuse much of the code from any Cisco stuff to also interact with other vendors, so under the covers they have to build something like 5 completely separate tools to admin wireless in a multi-platform way. Then because of the market segment they target they have to be able to sell it for cheaper than the vendor specific tool for each of those products. Doesn't seem like an offering that is likely to make a lot of money.
One of the strengths of the Orion platform is that it is relatively cheap to buy, and extremely open in a way that if you get clever you can make it do a lot of things that SW themselves didn't plan on. If you were dedicated I expect it would be possible to build some back end database integrations between Orion and Prime so that you could look at an AP in NPM and have it display on the page all the relevant info from Prime. I've linked Orion to lots of other tools through SQL. It wouldn't allow you to drop your Prime licensing, and ultimately I think your would still be working in Prime to do things like your firmware upgrades but it could reduce friction when navigating between the various tools your company uses. NCM already does firmware upgrades and config changes for the WLC itself, and I suspect that if you worked on it enough you could figure out a way to make NCM handle the AP's directly, but that's a lot of DIY stuff just to try and reinvent features of Prime.
I think of Orion as an adjustable wrench, it's convenient and you can use it for lots of things and it will do an okay job at it. But if I need to rebuild my engine my wrench won't get it done, I'll need to get a dedicated set of the appropriate tools. And to take that a bit further, the tools I use on a BMW engine are often not the same tools I use on a Ford engine.
There were wireless heatmaps to show some of this in the old NPM maps. It wasn't as in depth though, as marcnetterfield points out. jblankjblank is that wireless heatmap stuff somewhere on the horizon to look at for the new environment (if people use it?)
This is not an immediate item to tackle for the Orion Maps project at this point in time. I think this thread is great information to share with the NPM PM jason.carrier and we may be able to do some collaboration in the future based on their set of priorities. rajasekar you provided a great list of features that are important to you. Perhaps you can also share the Wireless vendors and models you are hoping to see these additional data points from. It appears to be Cisco but any additional info is welcomed.
