> I had more user connectivity complaints with the new system > than we’d ever had with the old gear
I might attribute that to band steering. Dual-band clients in older lightly covered areas will suffer. Rand Rand P. Hall Director, Network Services askIT! Merrimack College 978-837-3532 [email protected] If I had an hour to save the world, I would spend 55 minutes defining the problem and five minutes finding solutions. – Einstein On Fri, Nov 7, 2014 at 8:15 PM, Steve Bohrer <[email protected]> wrote: > 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/. > > ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
