Thank you both, for your insight. We've been testing for the past few weeks and I have to say that Meraki is "as advertised" in terms of their ease of configuration and deployment. We're going from n to ac, so I expect there to be fewer problems than a g to n migration.
Coverage gaps are a concern, but we should be able to more easily address those on a case-by-case basis due to the ease of meshing in areas that we previously couldn't run cable to. -jh From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Steve Bohrer Sent: Friday, November 07, 2014 8:53 PM To: [email protected] Subject: Re: [WIRELESS-LAN] Meraki Evaluation Hi Rand, Thanks for your comments to the wifi list about Meraki's lack of transparency. On Oct 27, 2014, at 2:47 PM, Hall, Rand <[email protected]<mailto:[email protected]>> wrote: [...] We recently blindly updated the firmware before school started and appear to be paying a price. That price is at least two-fold, APs regularly stop accepting connections until rebooted (not cool) and reverting to previous firmware doesn't seem to be an option. Engineering is on the case, but tight-lipped. [...] We've also had a few MR16s start failing recently. I don't expect them to last forever but hope this is not a trend. We switched to Meraki from an aged Cisco WLC/WCS system last January, and now have 110 MR16 APs. We are only about 1/8th your size in terms of student population, though our campus is fairly spread out, so I probably need about another 25 APs to cover most of it with reasonable density. I had four or five AP failures within the first couple months of deployment. Our symptoms were the AP would be completely non-responsive, with only the power LED glowing orange, no other lights or activity. After four of these failures, they started offering me MR34s as replacements, which was a pretty sweet deal. Then, after seven such failures, they released a firmware update in early June that seems to have stopped these particular failures for us - I've had one MR16 die since then, but it was just totally dead, no LEDs lit at all, so this is perhaps just a random failure, rather than the same pattern. Still, they never really admitted that there was a firmware issue causing the failures. They just emailed me specifically to suggest that I installed the June update as soon as possible. The notes they sent about the changes are very vague: * New VLAN debugging tools to help detect VLAN configuration problems * Distributed layer 3 roaming (no concentrator appliance required) * 802.11k (radio resource management) and 802.11r (fast BSS transition) wireless protocols * Hotspot 2.0/802.11u wireless protocols * Enhanced stability and performance improvements I guess the "enhanced stability" means that MR16s stopped bricking themselves. I asked specifically about this, and was told that the details of the update were "proprietary". Still, it seems to have done the trick. Thus, I was surprised to read that the recent firmware updates were giving you problems, as I've not seen this, so far as I know. However, perhaps the issue is different versions of the MR16 hardware; if everyone else was seeing the nearly 10% firmware-caused lock-up rate that I saw our first six months of deployment, I hope I would have heard of it. Thus, I'm guessing most people didn't have the "orange power LED" failure; and similarly, perhaps your issue is only with your specific MR16 revision. (Not, of course, that the system gives us any info about different possible hardware revisions, so who really knows. Maybe all MR16s are identical, and it is just random, or based on some difference of deployment.) Anyway, I'm wondering how you are tracking the problem. Do you just get user complaints when no one can connect, or is there some way to automatically monitor the dashboard, and reboot APs that have had zero clients for a long time? (Is there a report that gives daily users per AP? I have not found anything better than checking the APs list several times a day, though it would be handy to see peak client counts and such.) Is there any way to proactively reboot groups of APs early in the morning or something? Thanks for any insights you can share. 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/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
