Monitoring Wireless Capacity

In my last post,  http://wp.me/ps6Jj-am I talked about wireless network challenges, what to look for and how to plan properly for a deployment. I talked about planning for capacity to ensure you don’t go over a certain number of users per AP.

So, the next challenge becomes, how do I ensure that as I grow I don’t begin to exceed the optimal number of users per AP.

This is where advanced network monitoring can help mitigate issues before they become a problem. In the past a network monitor would poll or ping an access point to ensure it is available on the network. Although this is helpful it does nothing to monitor capacity.

Capacity planning is critical to any network management system. Bandwidth, CPU and Memory needs to be monitored on all your network devices. Each configured with a baseline that will alert you when that baseline is exceeded.

Recently we added some new capabilities to our Network Management System to cover Wireless Capacity Monitoring. Our monitors allow me to set the number of associated users threshold to the number of my choosing, either per AP, per Controller or any combination thereof. If the threshold is reached I can either send an email, log, open a ticket in our system, run a WEB service to another system, run a SPROC or do any combination of the above.

For our customers this will ensure a positive wireless experience. For us, it will help cut down on calls to our NOC regarding wireless performance issues, because we will be dealing with them before they become an issue.

This kind of monitoring is critical in less static environments like boardrooms, public areas with guest access and retail environments. In static environments where you know the number of users it may be less critical, but as users may move around, change their daily patterns, or over time you hire more staff, these changes can overload one AP, affecting the user experience and possibly productivity.

Setting all of this monitoring up may be time consuming in the short term, but can save you hours and hours of troubleshooting in the future.

Wireless Networking Challenges

Not too many people are plugging their laptop into an ethernet cable anymore. In fact, just about everyone in our office relies on wireless for their connectivity. In the past, wireless was too slow and somewhat unreliable, but it has come a long way and the convenience of not having to plug in far outweighs the performance impact if any.

Coverage is obviously one of the key elements for a good wireless deployment. It needs to work in your office, in the boardroom, in the lunch room and maybe even at the picnic table just outside your building. Ideally it should work anywhere your phone, tablet or laptop goes.

What gets missed quite often is planning for capacity. Coverage ensures there is a signal, but each access point can only service so many clients before it becomes slow, unresponsive and ultimately useless. It is also important to understand the applications that will be used over the wireless to get an idea of how many users per AP is ideal.

Some vendors make a recommendation of 20-25 users per AP. This is probably a good number if they are web browsing and checking email, anything more and I would suggest you will run into problems. In some cases, where large files are being saved to servers on a regular basis it is advisable to stick with ethernet. Overall however, I would suggest that you don’t want anymore than between 10-16 users per AP.

Interfering APs may also have an impact on your deployment. In some cases I have seen an AP detect up to 59 neighboring APs. This can cause havoc with your deployment. Site surveys prior to your deployment can certainly help mitigate this, but remember that a site survey is done at a point in time. If there is a new office building going up next door, you can expect more interference in the near future. Site surveys are good for determining the most effective placement of your APs and some tools will help you plan based on capacity as well.

When APs were standalone the deployments were much more complex than they are today with Controller based APs. The controller centralizes the configurations and pushes them out the the APs. Since the controller has a holistic view of the entire network, it can instruct the APs to make channel adjustments without affecting its neighboring APs. One of my favorite features in a Controller based deployment is the ability to detect rogue on-wire APs and even block any clients from joining them. A rogue on-wire access point is a AP that has been installed on the LAN via ethernet, but is not part of the controller based system. When configured, the controller will sent out disconnect messages to any clients that attempt to join the rogue AP.

My only complaint with a controller based deployment is that the cost is much higher than a standalone deployment. The Controller based AP is the same cost as a Standalone AP, but the controller hardware and licensing is extra.

The list of environmental challenges that can affect your wireless deployment is endless. Elevators, Microwaves, Cordless Phones, Water, Steel, Concrete, Small Rocks, you name it. They can all have an effect.

And of course security. One of the most important aspects of a good wireless deployment is ensuring only you and your staff can use it. A good deployment will have LDAP or RADIUS integration. If security is top priority then you should consider coupling the LDAP or RADIUS with a second factor, using key fobs or software that provides OTP (one time passwords).

The same AP’s that access your corporate network can also provide guest access. When providing guest access you can make it difficult so that only people you authorize can use it, or you can make it simple and provide a splash page where guest users are asked to provide an email address or simply agree to the terms of usage.

 

 

Meraki and Cloud Management

The cloud is taking over IT…. What are we all going to do when everything is cloud managed? Will we all be out of a job?  It is true the the Cloud is becoming a big thing, but like all changes in technology the devices and applications in the cloud still need to be managed and maintained by someone.

Meraki have taken the Cloud  a step further by providing a Cloud Managed Network. This is a great concept and can really simplify the deployment process. The Piece that is missing from this concept is that the Cloud doesn’t actually manage the network. The skilled technical folks that have that ability to isolate a problem and solve it are still required, regardless of the platform for Management. Meraki have made it easier and certainly the less technical would find some benefits in the Meraki approach, but like so many technologies they are sometimes too complex to simplify, or the process of simplifying the technology leaves it missing some key elements.

Cisco’s purchase of Meraki  shows that Cisco really believe in the Cloud, but I am curios how they plan to integrate, if at all. Cisco’s attempt at moving down market with Linksys was a mistake, as I think most Cisco savvy folks would balk at any Linksys Product.

In looking at Meraki’s  products, it would appear that they are well ahead of any Linksys product and slightly behind Cisco Traditional IOS products from a feature standpoint  but obviously well ahead of any Cisco product from a Network Management standpoint, an area that I think Cisco have always struggled with. It will be interesting to see if Cisco try and merge their IOS into Meraki’s cloud Management.

Either way, this has next to no effect on the business of Network Management, as these networks still require Management, regardless of the management platform in which they reside.