SuperfluousAdjective

Not every system will call home, and if it does it is often an opt-in model or at the very least well documented. It is odd to secretly push a change to a product to allow for call home functionality with no statement on privacy or what is being transmitted. This should have been made clear. There are many organizations who cannot have network equipment in their environment that call home. Ubiquiti should have known this. Even if the data is anonymized it can still be a security risk or a compliance violation.

They are fourth. Cisco, Aruba, Ubiquiti, Ruckus... Beamforming is not unique to Ruckus. And coverage per AP is not something that anyone should brag about. Don't get sucked into Ruckus marketing. It doesn't matter if your AP can beamform around and through your crazy difficult environment. Wireless frames must be acknowledged by the client back to the AP. If the client can't reliably reach back to the AP you will have a lot of retransmissions and add RF interference. Proper RF site planning is still needed and highly dependent on client connectivity to the AP. Ruckus and their partners are well known for doing site surveys that say you need less APs to start due to beamforming as a method of trying to undercut their competition on price. Then when/if you need more APs for performance reasons they'll say it could have happened with anyone... which is true it could have happened with any other vendor, however, it is much more likely to happen from the vendor who is purposefully ignoring the challenges of client to AP connectivity to make a sale. Interestingly, a comparable Ruckus AP with the same QCA and CPU/RAM is often slightly more expensive from Ruckus than say Aruba, but they often say you need less APs to show a reduced overall cost. This is dishonest in my opinion and if your Ruckus reseller is promoting less APs due to beamforming without properly explaining the downsides they are not trustworthy. It depends on the use case and the needs/budget of an organization. Cisco and Aruba are best for on prem wireless. Meraki and probably Mist are best cloud based. Mist is still new so they lack a lot of features. A lot of their marketing is nonsense, but they do have an interesting approach. Most Meraki vs Mist bakeoffs will go to Meraki though due to it being the more complete cloud product. And Ubiquiti for the super budget conscious. You can do a lot better.

Ruckus only has ~5% market share. I wouldn't consider 5% a "top brand." They also had the Broadcom issues where they wouldn't or couldn't stop using Qualcomm QCAs in their APs so they got their R&D budget cancelled until their business unit was sold to a cable modem company. I wouldn't use Unifi because it lacks enterprise grade features and they don't have the capability to resolve bugs and firmware issues in a timely fashion... which is a problem when their latest APs don't work or they suddenly decide to start sending your data offsite.

If your organization deployed a self signed cert inside IOS they put themselves on notice when the cert was created. It is not a secret or mystery to see when it expires in IOS. The person who created the certificate is the one who is responsible for making sure it does not expire and create and unplanned outage. It is not the responsibility of your hardware vendors to proactively reach out to you when your self-signed certificates expire. Maintaining good documentation is a best practice... as is not self-signing certificates on routers in the first place. Use a real CA or at the very least an open-source certificate.

This FN won't impact the vast majority of users. This is only if you used an IOS device to create a cert which is typically done on ISR routers for voice configuration. As a general best practice you shouldn't be self signing certs with your network hardware. Just because you have the capability to it doesn't mean you should. Use a private or open source cert provider or your own CA. If you do issue a cert it is your responsibility to keep track of its expiration, not your hardware vendor. If for some reason you don't want to do this you could also just recreate a new cert, but it would be continuing bad practices.

What your asking is a violation of the EULA, so publicly you shouldn't have any luck posting here for it. You should always maintain support on your controller when running a WLC, especially Meru since they have a history of end-running RFC standards and have far more client compatibility issues than any other vendor on the market.

Their business model is to convince customers to improperly set up their wireless networks.. ignore surveys, ignore client density, ignore interference and just willy-nilly place APs anywhere you want on the same channel and like magic the laws of physics disappear. And if your performance sucks, or if your clients don't work with their wireless system because they break RFC standards it's not their fault.. simply wait for a firmware upgrade (if it comes) and add more APs while crossing your fingers that it'll work the next time. The benefits of adjusting NAV values on a single channel architecture only exist in low client density deployments, that's why Meru uses multiple channels for their benchmarks. But, in low client density deployments you don't need to mess with the RFC and WiFi in that way, modern wireless systems are more than capable of supporting the environment. However, if you need more performance or if you have a lot of interference, you're fubared on Meru's single channel deployments. At the end of the day they can't get around physics.

Their product was started to solve a specific problem that was prevalent in early stages of WiFi. With the advent of modern technology and protocols like 802.11r/k/v, etc it becomes less relevant and the architecture itself creates a bottleneck. Meru recognizes this which is why when they do deployments for high performance networks they turn off their single channel architecture and when they run their own benchmarks they use multiple channels. Using the auto-rf channel assignment functionality of modern enterprise grade wireless systems will provide you better performance than a Meru single channel architecture. And if you're using Meru as a multiple channel architecture over their competition you've seriously purchased the wrong product for the task at hand...

Whoever told you Meru is a big boy in the wireless space lied to you. Their single channel architecture is counter intuitive with modern wireless advancements and their marketshare is abysmal.

Yes they are. You get what you pay for. Compared to the low end APs from other manufacturers they have half the RAM, lower CPU, less performance. All reputable benchmarks show they fail to properly serve all associated clients higher density environments (40-50+ users per AP). If that performance is acceptable to you, that is one thing. But, they are not enterprise grade compared to the competition. In what way are they superior? What feature or hardware component exists within their product portfolio that makes them superior in any way to the enterprise grade WiFi product portfolios on the market? The fact is they lack standard enterprise grade features like advanced RRM, DFS, basic roaming standards, fails to see any benefits of 802.11acw2 MuMIMO over 20 clients (due to hardware constraints), etc. It is 100% about cost. There is no technical reason to use them over the competition unless the decision is being made on cost. Other solutions can be easier to setup and manage and provide more features and hardware performance. The reason you'd use Unifi is because you can't afford or don't want a true enterprise grade platform.

No reputable person sells Meru... let's put that on the shelf. Unifi is not in the same league as Aruba or the rest of the enterprise wireless marketplace. They are low end, underpowered APs with limited features. You get what you pay for.

This test was commissioned by Ruckus and is actually quite laughable in how biased the results were created. Unlike most wireless tests the configuration of each product was not released, despite asked for, and in some instances they purposely used outdated/deferred version of code (months prior to release). As Devin points out in his report, QoS is critical to a test like this where we are basically testing wireless video QoS. That is all this test is, a wireless video QoS stresstest/benchmark. But, we know from the results that Ruckus did not enable wireless QoS on competing products, which is why you see the results you have. Best practice configurations of competing products was not used for a specific type of testing that Ruckus knew they would win if they handicapped their competition with deferred code and no QoS. Additionally, Devin who isn't the most unbiased character in the industry, didn't actually run the tests. He simply observed. Ruckus designed and ran the tests themselves. Whenever doing competitive tests like this it is common practice to allow the respective vendors to set up their own gear or to release the configs to show there was no monkey business (as there was in this test). The truth is most of these APs use the same/similar Qualcomm chipset and the performance results for each would not be very far off with a properly configured system and unbiased testing.

The biggest difference is that Meru runs in a single channel architecture which isn't the best for higher density environments and can cause issues with certain clients. From everything I've read Ruckus has better management and performance. Meru has some marketshare in EDU in Europe, but is generally non-existent elsewhere. Meru was recently acquired by Fortinet for a the cost of a toy in a Cracker Jacks box. If choosing between the two it's a no brainer to give a stronger look to Ruckus. Just don't let them convince you that you need less APs to get coverage as a method of lowering their cost. That's their sales strategy and is FUD.

Meraki MDM is free and works well. Airwatch is worth looking into as an affordable enterprise grade alternative. There's only so many hooks you can use so most MDM products will have the same features.

Todd Lammle and Wendell Odom books are great. Jeremy Cioara from CBTNuggets also has some great resources and explains the material in ways that is typically very easy to understand. You're asking for a broad range of knowledge, in order to configure this stuff you really need a background in networking. CCNA study materials are probably your best bet, even if you don't use Cisco equipment. One thing I noticed from your post is that you didn't mention the use of a firewall. That may be something you would want to include in your network upgrade if you don't have one already and this site has a direct link to the internet.

You would have to create a new VLAN and a new DHCP scope. Within your VLAN you would have to add a helper address to your DHCP server. In order to do this you will need an enterprise grade WAP that can handle 802.1q encapsulation/tagging. From there you can create unique web filtering policies and access control lists if desired. To set up the helper config on a Cisco/HP Router/L3 switch just add this to your vlan interface configuration: ip helper-address Repeat for for each vlan or SSID you want to segment. Very simple. Only has to be done at your school's devices that are configured for L3 routing.

Continuity. A virtual controller runs internally in the WAPs or via a VMware image. No downtime due to a single point of hardware failure within the wireless system. You get built-in redundancy for no additional cost. A cloud controller would be Meraki or placing a VMware image out in a private cloud. In Meraki's case your data is stored across three data centers with failover for redundancy. Your wireless network continues to run during any outages to your WAN or during failover to another one of their data centers. You also don't have to worry about managing the hardware, powering it, running firmware/software updates to match APs/controllers, etc. If you go with a hardware controller you not only have to purchase the expensive controller up front and pay for licenses/maintenance/warranty over time, but you are also limited to a single unit or potentially doubling your costs for high availability. When we went with Meraki for some of our installations the educational discounts (and I have seen corporations receive the same) resulted in less annual fees than virtually all if its competitors ($45 USD per AP with no up front hardware controller or fees associated with the controller). This $45 annual fee includes the cloud controller, 24/7/365 tech support and overnight replacement of any hardware. By comparison another vendor we use charges 10% annually on the MSRP of all hardware including the required 4 controllers. Over 5 years it is actually cheaper for us to rip out the entire system and replace it with Meraki and we know we would see a performance increase as well.

Just as a side note if you create a separate vlan you would have to make sure to manually forward DHCP traffic back to your DHCP server (with an additional scope) within your layer 3 device. Not difficult, but thought I'd mention it in case you found it useful. That's pretty much the only catch of adding a vlan on a basic network. Obviously the broadcast traffic will not span across the two networks so make sure to mitigate any issues with that. And with only three routers it isn't too big of a deal to update a statically routed network and the commands for your devices should be easy to find or replicate by looking at the running config.

If it is the same site and the same scope I would change it to a /23. If you can segment your network for servers, printers, wireless, etc I would create a separate VLAN, but a /23 network is acceptable for computers. Any more than that and I would recommend segmenting for performance. If you change your subnet to a /23 you would have 192.168.1.0-192.168.2.255 (1.0 being the network address and 2.255 being the broadcast address). The other sites could all stay at /24. This change would not effect their networks. You will have to change all the subnet masks for your devices at Site A either manually or via DHCP (don't forget printers, servers, statically assigned devices). And you will have to update the routes between your sites to reflect the network change. Are you routed statically, eigrp, ospf, etc?

Single channel networks do not comply with the expectations of the 802.11 protocols and client devices. The changes that Meru makes to enhance their single channel product makes it an unpredictable environment for drivers/clients creating connectivity/authentication issues that would not exist on other networks. Because of this it also makes troubleshooting more difficult. This is well documented throughout the field.

When this article was written the MR24 was brand new and had some firmware issues. You can see that with the report that they had trouble running 5 concurrently connected clients. This is not representative of its current performance. I was at a symposium recently where Meraki provided wireless access to 65 connected users in the same room with a single MR24 flawlessly. They invited 120 people, 65 clients authenticated to the wireless. Meraki showed up with a single MR24 and a power injector to handle the event, that is how confident they are with their product. One presenter was an audio/video Skype for 45 minutes. Not a single hiccup or moment of choppiness.

Everything Cisco is more expensive. They have a very large marketing base, hire the industry's best engineers, use top quality components and manufacturing processes. Their products tend to be bulletproof and they are often considered the industry standard and what other vendors compare themselves to. Nobody wants their products to cost more than Cisco because they have brand recognition, reliability and the "nobody got fired for buying Cisco" mentality. They can get away with charging a premium that other vendors typically can't unless their competitive products are highly specialized and industry proven. So most vendors will try to price their products below Cisco. Do you "need" something that expensive? Probably not, but there is nothing wrong with spending the quality money on a proven wireless system from a highly reputable vendor. Different wireless products will suit organizations differently. For some, they need uptime, something that will work predictably, good support, and lots of information available online for troubleshooting. And the CTO will typically have a lot of pressure to buy something that won't cause headaches down the road. Buying Cisco safeguards the purchase in that everyone knows the name and knows it is trusted. You will typically have very few problems with their products and when something goes wrong you have the defense of buying the Cadillac product. In other words, a lot of people buy Cisco to cover their butts. If you tell your boss that you're going to try out this start-up company's product that is an industry first in putting the smarts of the networking out in their data centers and hope the company doesn't go bankrupt before the product is end of life you might be looking for new work if your investment blows up in your face. I don't have experience with Ubiquiti products, but they are highly recommended by people who use them because of their price point. People who try them consider them to be a terrific value of features and performance for their low TCO. Ubiquiti doesn't have a cloud controller as far as I'm aware. Pretty sure it is software based, which means you could put in a the cloud if you wanted to, but that would be on you to do so and manage high availability/failover. Meraki, on the other hand, does have a cloud controller. Your configuration is stored within three of their half dozen data center locations around the globe so there is built-in high availability into the system. The access points download their configurations and can function at 95% feature set even if they do not have connectivity to the controller. Whereas with an on-site hardware controller you would have to purchase two controllers if you wanted high availability. Otherwise you would have to wait until you can have a new controller delivered to you and configured. Some vendors also offer VMware controllers, and you could accomplish this with Ubiquiti yourself if you wanted to go that route. This would negate the lack of high availability other vendors have. As far your subject heading is concerned "Choosing an access point?"... first you should choose the type of wireless technology that suits you best. Single-channel architecture or multi-cell. Both architectures have their pros and cons. If you choose single-channel you are pretty limited on your choices. If you choose multi-cell you should then consider what type of controller deployment works best for you. Your options pretty much are: hardware controller, software controller, cloud controller, or a controller built into the APs themselves. Personally, I see the days of the hardware controller being numbered. They require on-site service/maintenance and typically aren't deployed with high availability. Then in regards to which access points to choose I would highly recommend getting access points that are 5.0GHz compatible and match up the radio specs for your needs/hardware taking into consideration future growth. And don't forget 802.11ac is around the corner, if this is something you would need instantly as it becomes available to enterprise wireless networks I'm pretty sure only the newer Cisco 3600 series APs allow for bolt-on modules for 802.11ac functionality. You'd also have to make sure your switches/power source can power the AP + module. And don't forget to look up educational discounts and take bids (typically required for public school districts by most states unless using an approved vendor). Cisco actually ended up being priced competitively and in many cases cheaper than a good chunk of companies who bid with us. We have a very strong relationship with our local Cisco reps so YMMV.

What device, wireless nic, nic driver version are you using? Have you run a packet tracer to monitor the authentication process if there is one?

I would check to see if the wireless NIC has a driver update. I'd also run a packet tracer. Depending on your Meru configuration it will not beacon itself until the client announces itself. And when it does beacon it will send out a unique MAC address/wifi network for the individual client. Your host device may not be passing the traffic needed to get a response/connection from the Meru system. I'm sure one of their engineers can assist you best, but dealing with these inconsistencies is part of the deal when going with a single channel system that breaks away from the wireless protocol standards.

We inherited an Extricom system and found the product to be severely lacking on features and performance, especially for the price. Coverage is about half of a traditional access point in the US (assuming radio power is lacking despite set to full). A standard SOHO Linksys in the US will provide double the coverage range as one of Extricom's higher end "access points." The initial price was very expensive considering the 1:1 radio/switchport on their controller as well as outrageous cascading software costs (~$10k USD) to allow two of their controllers to talk to each other which is needed if you require more access points than a single controller can provide for due to port density (max 16) or distance. And recurring annual costs of 10% MSRP on all hardware for support and warranty is more expensive than going with a cloud based controller+licensing. Their "access points" are more expensive than comparable products and they have no inner smarts. They are simply radios at the end of an Ethernet cable, yet they charge more than the competition for their access points. The whole setup becomes very expensive, very quickly. That coupled with the fact that it is a single-channel architecture that does not come with packet management by default (TrueReuse) and requires an additional fee as well. I wish I could say they "nickel and dime" you for everything, but that would imply small fees for everything that adds up quickly. These are large fees that make the product outrageously priced for the features/performance you get. We wouldn't mind paying a premium for a system if it actually worked well. We recently received a bid from Extricom for three sites using a 2x2 access points and TCO over 5 years was triple that of a Cisco system with their top of the line 3602i (4x4) access points w/ CleanAir licenses (same # of APs as Extricom bid). For a single channel architecture Meru is really the only way to go as far as I'm concerned. It is a more mature platform. Extricom is just ridiculously priced. The controller works out to cost roughly $450 USD per port (AP) and each AP is roughly $900 USD. When you work out the annual license agreement it works out to be about $700 USD per controller (max 16 ports) and an additional $90 per access point. And because of the weak coverage you need more access points than you normally would have. To put the costs into perspective, with a cloud based system like Meraki you would pay $45 a year (5 year EDU plan) and not have to outlay any up front costs on controllers/software. This includes tech support, 365 next day replacement, cloud based controller, and all licenses. It also trumps Extricom in performance by leaps and bounds. Extricom has been around the block for a while now (founded in 2002, sales went out 2005), but they still operate as a loosely managed startup that has been unable to penetrate the market at any capacity. This is no accident and it shows in their product development. By comparison in this thread, Ruckus was founded in 2004, two years after Extricom. Yet, no one would consider Ruckus to be a startup, nor does the company behave like one in their sales, R&D and product progression. Extricom is Meru's only real competition in the single-channel market and I would hardly consider them a real threat. Meru is the only single channel product that has the engineers and vision to make a competitive product in the enterprise wireless marketplace.