Here's my feedback:
1. Initial configuration was easy. Just added new node using Meraki API polling type and entered API key. Ran into one issue with the API key from the Meraki dashboard side. Turns out I can't generate an API key using a user that authenticated with SAML. I had to login with an admin account that was defined inside the Meraki portal.
2. Meh. Six of one, half a dozen of the other. With AP's added as individual nodes and SNMP polling, I was getting Node name and accurate model info (populated as Description), SSIDs, current channel (never more than one) and node specific response/packet loss. No AP error info or wireless client info. When viewing the same node through the Meraki API node, I get the wireless client info and AP MAC address. Would be nice to get a combination of the two polling methods to fill in the missing pieces between each other.
3. Not yet.
4. My wishlist for Meraki wireless is to see NPM provide the same info as I can get with most other AP's. Ultimately I want to be able to provide the same detailed information that makes NPM the true one-stop-shop for wireless troubleshooting -- heatmaps, signal info, channel utilization, etc. My main reason for this is to be able to confidently say to my team, and others, that NPM is the definitive source of information for all infrastructure -- not to have to say that NPM is good for X, and Y, but if you need Z you have to go somewhere else.
Like branfarm, I'm a bit "Meh" on the Meraki monitoring.
The licensing angle is very appealing, as we can monitor all 53 APs using just one interface instead of 159 - but right now the rather sparse data presented makes this a dubious trade-off.
Pros: The lists of active clients are useful
Cons: No obvious way to sort the list, even by name - so searching for a particular AP is annoying.
In the List Of Thin APs table, the channels column is empty
In the Active Wireless Clients list of an AP, the SSID, signal strength, data rate etc columns are empty.
Pros: Monitoring APs and alerting of failures etc is more in line with the way wired nodes work, it seems to fit better with the interface and our approach to using NPM.
Cons: A lot of missing data in the default node view: utilization bar-graphs of the wired and wireless interfaces are empty, for example.
No information on connected clients, as always with the SNMP approach.
So as branfarm said, a hybrid approach of both monitoring methods would be best at this stage, but even so there is still a lot of data missing compared to the actual Meraki Dashboard - although of course this may be a limitation in the API itself.
Thanks for your feedback.
Had trouble finding where to enable the API key. I kept looking in the wrong place.... This link helped with that: The Cisco Meraki Dashboard API - Cisco Meraki
As dominicthomas stated, kinda need to do a hybird of monitoring both via dashboard and snmp to get the data you want.
1) Very easy initial config. The delta between nodes natively monitored with snmp and those only seen via API is obvious. Also, in my case I cannot see to get SSID, channel or client info out of those APs that are API only. Tried deleting and updating this setting (Meraki APs not showing after adding the new dashboard - SolarWinds Worldwide, LLC. Help and Support)then adding back but no change?
2) At this point I'd say no. Yes the SNMP nodes (Autonomous APs) show SSIDs and Channels but either show any clients.
3) No given the missing info using this for troubleshooting would be difficult
4) I agree with Branfarm above. Additionally, I read in another thread we cannot use the API to monitor status (Meraki Monitoring in NPM 12.1 ) If this is true that will defeat much of the functionality for me too.
1. Really easy
2. Yes and no - data is all there but its not correlated. We have the AP;s added with SNMP also. My engineers just stay in the meraki dashboard as that has all the information they need - that means the take up of Solarwinds as our default monitoring tool is low.
3. No, as i said the Meraki dashboard is still the go to tool for trouble shooting by engineers, SNMP monitoring of the AP's in NPM enables us to have the availability tickets in ServiceNow automatically. If Meraki had better alerting and reporting then SW would lose.
4. Get the data from the Meraki W-AP's to the same standard as the Cisco devices on a wireless controller
Don't get me wrong its a well needed 1st step, well done, must do more....and whilst you are on it how about fixing the other Meraki devices...now you have solved the cloud access issues with Meraki, get more monitoring infor for the MX devices and Switches...Its hard to convince people of the professionalism of NPM when it reports a firewall device as a Wireless Autonomous AP
I couldn't use my API Key to poll Meraki Environment with NPM 12.1
It keeps saying me -
Failed to get list of organizations