Kevin - 25 APs is getting on the heavy side for managing them individually. We had around that number of Cisco FAT APs and management was very difficult. I didn't have an easy way to determine usage, upgrade software, update configurations or do troubleshooting. Going to a controller based system has been wonderful. Meru makes a controller for up to 30 access points before you step up into bigger gear. I'm not familiar with Aruba, but I expect they do as well. I highly recommend you go to a centrally managed system, rather than trying to manage your APs individually.
Tim Winders | Associate Dean of Information Technology | South Plains College > -----Original Message----- > From: Kevin Whitney [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 14, 2007 1:34 PM > To: [email protected] > Subject: Re: [WIRELESS-LAN] Cisco vs. Meru article > > May be a little off subject but I would like to post question out there > as it seems there are some happy Meru users here on this forum...... > > Any thoughts or advice on implementing/selecting a wireless system for > use in a High School environment ? > > Specifically, would love any feedback on pros/cons of a central > controller based system (ie -Meru, Aruba, etc) vs installing Fat AP's > around our building. > > While our needs are quite simple I am sure, compared to the size of > other user's who have posted, I can see there is a great deal of > knowledge and experience in this area. Basic site surveys conducted > here > have indicated we need somewhere around 25 access points to provide > coverage throughout our building. > > Appreciate any input on this subject. > > Kevin Whitney > District Technology Coordinator > Cresskill Public Schools > 1 Lincoln Drive > Cresskill, NJ 07626 > 201-541-4162 > [EMAIL PROTECTED] > http://www.cresskillboe.k12.nj.us > > > > > > -----Original Message----- > From: Dave Molta [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 14, 2007 12:21 PM > To: [email protected] > Subject: Re: [WIRELESS-LAN] Cisco vs. Meru article > > Debbie, > > They were Intel 2915 clients. I have some pretty dense spreadsheets > covering various permutations of clients and infrastructure if you are > interested in seeing raw results. We didn't come away from this with > any > firm conclusions about what's good and what's bad (I guess we've > learned > our lesson about pointing the finger too soon!). What was most > interesting to us was the fact that there was so much variation, which > is something we didn't expect from such a mature standard. > > dm > > > -----Original Message----- > > From: debbie fligor [mailto:[EMAIL PROTECTED] > > Sent: Thursday, June 14, 2007 11:59 AM > > To: [email protected] > > Subject: Re: [WIRELESS-LAN] Cisco vs. Meru article > > > > On Jun 14, 2007, at 10:24, Dave Molta wrote: > > > > > Just to elaborate a bit, the article James sent around was not the > > > original Meru-Cisco feature story but rather a column that > > reports on > > > results of subsequent testing. In this column, I reported three > > > things. First, Cisco was unsuccessful in getting the Wi-Fi > > Alliance to > > > rescind Meru's certification. Since WFA certifies interoperability > > > rather than standards compliance, this is not proof that Meru isn't > > > stretching standards a bit but it still casts a cloud over Cisco's > > > allegations. Second, I reported findings from subsequent > > tests where > > > we added Aruba to the mix and found that Cisco's performance also > > > cratered when co-located with Aruba gear. > > > Again, that could indicate that Aruba is also somehow > > playing foul as > > > well (Cisco speculated that they might be using a variation of PCF > > > interframe spacing, though Aruba denied it) but it doesn't > > look that > > > way to me. Finally, we decided to re-run these interference > > tests with > > > different mixes of clients, using Atheros, Broadcom, and Intel > > > chipsets. We found significant differences in the > > performance results. > > > Atheros-based clients performed best. > > > > Something I noticed in the article was that Meru did the worst with > > Intel chipsets, but which chipset wasn't mentioned. > > > > The 3945 Intel micro code bug makes them work very poorly with Meru > > and causes some problems with other vendors APs. > > We've been waiting for an update from Intel, but still don't have it. > > > What Intel has done is ceased to sell that chipset > > -- this worries me that there wont be a microcode fix, but at least > we > > > wont have new equipment coming in with that card. > > > > So if the testing was with all 3945 cards, I don't think that > > accurately indicates Meru doesn't work well with Intel in general. > > Dave do you happen to know what the cards were? > > > > For those not following the problem with the 3945 cards, there is a > > bug in the micro code that causes it to crash if it sees out-of-order > > packets from the same AP. I heard this from an Intel employee on a > > conference call with them and Meru. It had been replicated in > Intel's > > > state-side offices and finally at their development site in Haifa > last > > > February just days before our phone call. > > > > Since all Meru APs look the same to the client, it's easy for things > > to be out-of-order like that. The initial work around of setting the > > power save mode to off didn't work, not because it was the wrong work > > around, but because the driver kept taking it out of "never power > > save" mode. If you update to the latest Intel driver, and then again > > set it to not use power saving, it stays set that way and the > > disconnects go away, at least for the ones we've tried it on so far. > > > > > > > > The broader issues here relate to standards compliance > > (e.g., to what > > > degree can a vendor selectively implement certain elements of a QoS > > > standard?) and, perhaps more importantly, performance issues with > > > Wi-Fi that may arise in the future as the density of > > deployed networks > > > results in increasing levels of co-channel interference. I am > > > particuarly concerned about the intersection between private > > > enterprise WLANs and public metro Wi-Fi networks. It may > > not be a big > > > problem today but I wonder if it will be a problem in the > > future. We > > > understand that our tests represent worst-case scenarios that few > > > enterprises currently experience but sometimes there is value in > > > pointing out the worst-case situations. > > > > It's always good to know what to keep an eye out for when you're > > designing something. We're not seeing problems in our still Cisco > > buildings that are near Meru buildings that we are aware of, and the > > users are pretty good at telling us if it quits working. > > > > > > > > If there's a silver lining here, it may be that 11n is > > likely to push > > > most enterprises towards more pervasive 5 GHz deployments, where > > > co-channel interference is not such a big issue. > > > > > > dm > > > > > > > > ----- > > -debbie > > Debbie Fligor, n9dn Network Engineer, CITES, Univ. of Il > > email: [EMAIL PROTECTED] <http://www.uiuc.edu/ph/www/fligor> > > "My turn." -River > > > > ********** > > 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/. > > ********** > 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/.
