Hi Jeremy, Sorry to be so late to reply to this thread. We replaced a near-EOL and at-capacity Cisco WLC/WCS system with Meraki last January. We’ve had a few bumps, but things mostly work. We are a very small college, so our full system is just 110 APs. We went with the 2x2 MR16s, but have upgraded a few to their 3x3 MR34s. The MR16 is now replaced by the MR18, which seems like a good thing, though I’ve not tried any of them yet. These newer APs have an “extra” radio for rogue and noise monitoring, so you get more information about your airspace.
One thing I’d recommend is: have a site survey done, and deploy the recommended APs exactly where Meraki thinks you should. In our case, we replaced our 75 old Cisco 1131AG APs, and also added 35 new ones to expand coverage in three dorms. Thus, for the bulk of our deployment, location was not really an option, as the new APs were mounted right were the existing APs had been. I sorta figured that the new Meraki stuff would do at least as well as the ~8 year old stuff we were replacing, but this was not always the case, and I had more user connectivity complaints with the new system than we’d ever had with the old gear. Several times, when I opened tickets for help, the Meraki tech replied with, “Did you do a site survey?”, which we had not. From this, I’m thinking that their gear does really well in an ideal deployment, but maybe is not so good at making the best of non-optimal AP placements. (OR, I could be totally wrong: Maybe the issues were that previously, with our “AG" only coverage, clients were using old and well-debugged drivers, but when we updated to N radios, we hit more driver problems. We certainly had some issues with early Win8.1 drivers.) In two areas where many users had connectivity problems with the Meraki system, we replaced our original MR16s with MR34s, and the problems went away. So, maybe some connectivity issues are only with these now-discontinued radios. I certainly agree that when there are not any problems, the Meraki system is really easy to manage. Adding a new temporary SSID to a group of APs is really quick and easy, and initially integrating it with our existing RADIUS server was pretty simple as well. However, if you do have problems, the lack of data about what is actually happening with your clients can be frustrating. Early on, we had what turned out to be a MSTP problem with the AP VLAN, so the problem was totally my fault, not Meraki’s. However, their user-viewable “Event Log” does not provide any info about the AP losing its upstream connection, and thus going offline and dropping clients. (You will get an alert if the AP is off for five minutes or more, but 30-second drops for bogus MSTP re-convergences are invisible.) I finally got a clue to the problem when a user complained that his tablet and laptop had both lost their wifi connection simultaneously. I looked at the AP’s log and found nothing, so I opened a ticket, and the tech told me that according to the AP's secret, non-user-accessable log, it had lost its connectivity for 30 seconds. I think it would be handy for troubleshooting if such events made it to the Event Log that is visible on their Dashboard. I also agree with Rand Hall at Merrimack’s points about “lack of transparency”, particularly with respect to firmware updates. We had several MR16s fail within a few months of deployment, and support never mentioned that there was any known issue with the MR16 firmware bricking some APs. Eventually, however, they released a firmware update that seems to have resolved the problem, even though they never said specifically what the issue was. On the plus side, they are very fast about replacing failed APs, and after the first few, they offered me upgrades to the MR34 for each MR16 that failed, so that was really nice. Not sure what other systems you are looking at. In the course of our evaluation, I also really liked Ruckus and Aerohive. Ruckus’ software on the controller didn't have many fancy features, but their radios totally just work. In the testing I did in our problem coverage areas, they were really great, and actual client device throughput seemed significantly better than with other systems. Aerohive (unlike Meraki) has a ton of data available for monitoring and troubleshooting, but with the trade off of being more complex to configure initially. They have a really nice report that identifies client devices that are having connectivity trouble, so you can proactively sort them out, rather than waiting for user complaints. Also, they have a more sophisticated “mapping” feature than Meraki, using plans of your buildings with the walls drawn in, rather than just a general map. This lets them locate devices and rogue APs much more accurately than the Meraki system does. Also, in our quotations, Aerohive was significantly cheaper than Meraki, particularly in terms of annual support costs. I think we might have gone with Aerohive, except that in the end Meraki gave us pricing good enough to remove cost as a factor, and my boss likes the Cisco name. Bottom Line: In a good deployment, Meraki is really simple and trouble-free. But, in less optimal situations, it may not give you much to go for resolving the problems. Steve Bohrer Network Admin, ITS Bard College at Simon's Rock 413-528-7645 ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
