As mentioned before, we probably won’t be using the new Meraki monitoring due to the significant increase in license cost. However, there are several benefits to that increase in cost:
- Meraki devices are devices instead of instances, so they’ll be able to do everything regular devices can do. That includes putting them into location specific groups.
- There are a few additional metrics provided that weren’t fetched before. Not sure if it wasn’t possible or if it just wasn’t added in.
- Local monitoring: since they’ll be devices, existing LogicModules can apply to them. That’s good because things like Ping can be used to distinguish between “device down”, “device not connected to Meraki controller”, and some of the false positives we would get from the Meraki troubleshooter DS.
- Not sure, but it looks like the monitoring is all (or mostly) done via the API. I’m still trying to work on why the netscan needs the community string if it’s coming via the API but it’s difficult to tell what the modules are going to do (and how). The module toolbox->exchange has the option of pulling in a package but doesn’t treat it as a package once it’s installed. I’ve not found a way of filtering by package so that I can look at what each of the modules do.
To give these benefits a try, I decided to give it a chance in my sandbox. Here are my findings:
- License count is per device instead of network. This changes the way the licensing works making certain networks financially equivalent to the old method from a monitoring perspective. For example, today, if we have a customer that has one network per retail store with one device in it, but has a thousand retail stores, the cost is pretty significant. We are paying for 1000 networks. That simply won’t work. However, if we have a customer with one network with 1000 devices in it, we are paying for one network. With the new model, 1000 networks with 1 device each costs the same as 1 network with 1000 devices. The cost for the retail customer doesn’t change, but all other networks increase in cost.
- You can filter by network ID within the NetScan by setting a credential property, not by setting anything in the filter section of the NetScan.
- You cannot exclude certain network IDs from the NetScan. You can only include, excluding everything else. For our use case, this is the exact opposite of what we need.
- If you want the discovered devices to be monitored by other than the collector running the netscan, you have to upload a CSV file to the collector.
- Why isn’t there a UI for this? Why isn’t there a wizard that lets you manage your Meraki cloud the same way you manage your AWS cloud account? If this were built, you could 1) test credentials, 2) ensure the right networks/devices are included, 3) handle collector mapping in much the same way AWS collector mapping happens, 4) not have to make sure you spell the 18 property names correct, 5) not have to copy and paste 475 lines of code into a NetScan, 6) preview the group structure (or opt out)
I didn’t even get to the point where I tested the netscan. When juggling a couple windows, i accidentally closed the tab where i was building the netscan. I didn’t get a warning using the onbeforeunload event.
For these reasons, I’ll have to wait another 3-6 months to see if LM can come up with any improvements.
Best answer by Joe WilliamsView original