Blog

Which Cisco WiFi Architecture is right for you – Wireless LAN Controllers, Mobility Express or Meraki Cloud?

I get asked this a lot… What’s the best fit for my customer – Meraki Cloud, Wireless LAN Controllers or Mobility Express?

As ever, the answer can be found be understanding the requirements the network has to satisfy and the scale it which it will operate.  Here’s a quick overview of the basic strengths and drawbacks of each;

Wireless LAN Controllers

Wireless LAN Controllers (WLCs) provide a single point of configuration and control across your Wireless LAN estate.  Whether you want to roll out a new SSID to one Access Point or 6000, you just make the change in your WLC and you’re done – everything updates quickly and consistently.  The current generation of WLCs from Cisco – the 3504, 5520 & 8540 platforms – undoubtedly offer the most feature rich experience.  If there’s a feature you need for your networking challenge, you will find it one of these platforms.  They all provide flexible, trust-based Access Point licensing and support a range of User and Access Point quantities;

3504 – Up to 150 Access Points & 3,000 Users
5520 – Up to 1,500 Access Points & 20,000 Users
8540 – Up to 6,000 Access Points & 64,000 Users

The drawback of using a physical WLC is that if your WiFi network is critical, you probably want two of them.  Each needs SFPs, Power Supplies and for the largest model, up to 4x 10Gbps interfaces.  These demands are occasionally hard for some customers to accommodate.  Also, as you might expect, Wireless LAN Controllers and their AP licenses aren’t free, so there’s a financial impact associated with buying them, and maintaining them in-life.

See here for the Cisco Wireless LAN Controller Overview

Mobility Express

A Mobility Express solution provides WLC-esque functionality by embedding ‘lightweight’ Wireless LAN Controller functionality in to an Access Point.  As you might expect, a small, relatively cheap Access Point doesn’t have the same power as a fully fledged Wireless LAN Controller so you do lose some functionality by comparison, most notably that Mobility Express solutions work in FlexConnect mode.  FlexConnect means that while there is a Mobility Express Controller Access Point keeping your configs consistent and managing the RF estate, the Users’ traffic is bridged directly to the LAN from whatever Access Point they are associated to; it does not tunnel the traffic back to the Mobility Express Controller.  There are a number of other limitations as well, but Cisco explain these thoroughly here.

Another important consideration about Mobility Express is the Access Point you’re going to deploy with it.  Different Access Point models can support different roles; some (newer) Access Points can be either a Mobility Express Controller, or a normal ‘subscriber’ Access Point.  Other (older, or lower spec) Access Points can only be a subscriber Access Point.  A list of which Access Points can fulfil the Controller and/or Subscriber roles can be found here.  Furthermore, not all Mobility Express Controller Access Points have the same capabilities – some can support greater numbers of Access Points and Clients than others.  A list of which Mobility Express Controller Access Points and their respective scalability limits can be found here.

So far I’ve mentioned lots of compromises, but the truth is that for many customers, especially those with small to mid-sized sites, the compromises aren’t an issue.  The obvious benefit of chosing a Mobility Express based solution is that you avoid the cost of the Wireless LAN Controller entirely, which in some cases can represent a large saving.  There is a secondary benefit as well; if you’re a border-line customer and can’t work out if you are best off with Mobility Express or a WLC, you can start with a Mobility Express solution on Day 1, but if you outgrow it you can still implement a Wireless LAN Controller at a later date and your Mobility Express Access Points can be converted to use a Wireless LAN Controller rather simply and easily.  My only real issue with Mobility Express is that, if you’re a customer with lots of small to mid-sized sites, then you will have lots of Mobility Express Controllers to manage, at which point you really need to be including Prime Infrastructure too.

Meraki cloud managed

The Meraki dashboard is bloody great!  If you want a GUI that is quick to learn and really easy to use, the Meraki dashboard is it.  Winner!  All. Day. Long.  However, let’s look at the offering in a little more depth.  Unless you start to incorporate an MX appliance in to your WiFi (more on this later), the Meraki solution works a lot like FlexConnect.  The Meraki dashboard manages everything and User traffic is bridged to the network directly from whatever Access Point the User is connected to.  Meraki has been accused in the past of not giving people enough bells and whistles to play with, particularly when it comes to RF management, but recent improvements to the dashboard have changed this and the product’s features are maturing very nicely, especially now we have support for the Cisco Identity Services Engine and Prime Infrastructure as well.

Unlike the Mobility Express architecture, the Meraki Dashboard natively supports multiple sites through a feature called ‘Networks’ (anybody else would have called it ‘sites’, but hey ho…).  The Networks feature gives you the ability to manage all of your sites through a single dashboard, neatly and competantly filling the gap that larger Mobility Express customers need Prime Infrastructure for.

So what’s not to like?  Firstly, it’s never as cheap as people think – a Meraki cloud solution will cost you, as near as makes no difference, about the same as a Wireless LAN Controller solution.  Secondly, and perhaps more importantly, the lack of technical detail.  Look at the other two architectures and there is very specific information about scalability limits, performance characteristics, what features are supported on what device and so on.  Try to find that level of detail with Meraki – it’s just not there – and that makes me, somebody who designs networks for a living, nervous.  Sure, they tell you that Access Points support Layer 3 roaming, but to what extent?  How many Access Points can be in a single roaming domain?  Do the limits vary with older/cheaper Access Points compared with newer/more capable ones?  How many Users can be in the roaming domain?  The same ambiguity can be found when you incorporate an MX in to the solution as well.  You can use an MX as an anchor point where all Wireless User traffic gets tunnelled back to, but nowhere can I find any limits published on how many Access Points tunnels an MX can terminate.

So in summary, whether you’ve got one small to medium sized or 500, Meraki is probably going to be a good fit.  If however, you’ve got one large campus (a big Corporate HQ, a University, a Hospital, etc), I’d stay away from Meraki and use a Wireless LAN Controller instead.

If you want to learn more about Meraki, click here for a free webinar.  Attend the whole session and you’ll receive a free Meraki Access Point (Meraki terms apply, see link for details)

How many Wireless Access Points do I need?

This is one of the more frustrating questions I get asked…  how long is a piece of string?!

I understand why people want to know – is it even worth doing a Survey if my budget will get blown, can I stretch to the better model of Access Point, how many PoE Switchports will I need to provide – but it’s not a quick or easy question to answer.

Before you ask this, or before you trust anybody who tries to answer, there are several things to consider;

  • What does the network need to do? (Data, Voice, Video, Location Tracking, RFID, etc)
  • On what scale will the network operate? (1 User or 10,000? How many devices per User?)
  • How will you quantify that the network is working well? (SNR? Bandwidth? Packet loss? User reports?)
  • What are the physical characteristics of your environment? (Open plan? low ceilings? Thick walls? Congested RF?)
  • What are the capabilities of the Clients using the network? (frequencies, transmit powers, phy, security capabilities, battery powered?)

I find it best to start with the desired target User experience and work back from there, via environmental considerations and device capability considerations, to arrive at an answer to the question.  Here’s a story of how requests like this sometimes go;

Let’s say you want a good, high performance network with Clients that are generally just browsing the Internet and sending e-mails – short bursty traffic flows.  Let’s further suppose you have a modern-ish fairly open plan office across three floors of a building with 200 people per floor.  You’ve recently splashed out on laptops and tablets so everybody has a device that supports 802.11AC and you want a ‘Wireless First’ network connectivity model because none of the Users can be bothered to drag around the brick that goes with their shiny new Surface Pro.

You’ll want to develop a target contention ratio of Users per Access Point to ensure everybody gets a fair amount of bandwidth to supported the anticipated usage; let’s say 20 Users per Access Point.  So, without even seeing any floorplans, 600 Users divided by 20 Users per Access Point gives us 30 Access Points as an initial estimate.  Let’s assume all of the floorplans are identical, so 30 Access Points across three floors leaves us with an initial estimate of 10 Access Points per floor.  With a bit of effort you also research the devices your Clients are using and you determine that you need a particular Signal Strength to let them hit the data rate they want; let’s say -67dBm at 5GHz.

Consider the layout of the floor, will ten Access Points realistically provide the coverage you want – at least -67dBm Signal Strength / +25dB Signal Strength @5GHz everywhere?  With lift shafts, stairwells, storage cupboards and areas that have particularly high or low user densities, you may end up needing 12 Access Points per floor, that’s 36 Access Points in total as a basic initial estimate.  Any experienced WiFi person will be good at estimating this off plan.  Many will give you “heatmaps” to show the coverage you can have, but if these are produced offline and without having gone to site, they’re just educated guesswork and must not be relied upon, and no, it doesn’t matter if they used Ekahau, AirMagnet, WCS, or whatever… it’s all guesswork.  No matter how impressive they look, they are not reliable.  If you want reliable results, do a proper site survey.

“You’ll need 36 Access Points” is the message that goes back to the customer, “but we’ll do a site survey just to check”.  An engineer goes to site and starts surveying for -67dBm at 5GHz with a target 20:1 contention ratio, but soon spots a problem.  Your office is in Zone 1, central London.  You’re surround above, below and on all sides by other Corporations all operating their own WiFi and the noise floor is much higher than expected.  To meet or exceed the minimum Signal Strength and Signal to Noise requirements, the coverage area of each Access Point has to be reduced.  This gives you a better User to AP contention ratio, but it increases the number of Access Points you need – let’s say you need an extra two per floor, so we’re now at 42 Access Points.

The survey continues and when the surveyor gets to the last floor, it becomes apparent the floorplan doesn’t represent the actual layout at all.  Instead of an open plan office, it has been divided up in to small meeting rooms with lots of floor to ceiling glass walls. The architect has used nice expensive, heavy glass that is hard for 5GHz to penetrate so to keep hitting your SS and SNR requirements, another two Access Points are needed on that floor and we’re now at 44 Access Points from our initial uninformed estimate of just 30.

You’ve read that 802.11AC can provide some really fast data rates – 2.6Gbps or so – can your 44 shiny new Access Points do that please?  In short, no.  With 14-16 Access Points on a relatively small, open plan floor, you’re likely limited to 40MHz channels to avoid channel re-use issues.  Rather than the sexy 160MHz channel 2.6Gbps rates you’ve been reading about from the Manufacturer’s marketing team, you’ll have peak datarates more like 600Mbps.

44 Access Points, 600 Mbps peak rate, fine.  Let’s get them installed.  Wait, why don’t they work?  Did you audit your LAN properly?  Newer 802.11AC Access Points need PoE+ or even UPoE to work properly.  Older switches might only support 802.3af and the one switch you have that does support 802.3at is at its power limit.  Access Layer LAN upgrade please…

The morale of the story?  When you ask one simple question – how many Access Points will I need – but you get 50 questions back with no sign of your question being answered, take the time to answer thoroughly, it will be time well spent in the long run.

 

How organisations weaken their own security without realising

A couple of real examples about how organisational disharmony causes security problems.

I visit a lot of customers with similar requirements… “our Wired/Wireless network needs securing“.  The solution is, more or less, always the same and it’s simple enough to implement when you’ve been through the process so many times.

Simple enough says I, but it requires different parts of an IT team that are so often like oil and water, to work together seamlessly.  Yes you’ve probably guessed it, we need the Network Team, Server Team and Desktop Teams to all work together to deliver one secure solution.

In some (rare!) cases, IT Teams are multiskilled and get to work with one person who has access to, and good knowledge of, all of the systems involved.  Bliss!  One person who can read a Security Policy and who can work with me, through lots of systems, so they can see how their policy is implemented end-to-end – Clients, Switches, Wireless LAN Controllers, RADIUS Servers, SSL Certificates, Domain Security Policies, Troubleshooting Methodologies, approaches to managing change, and so on… perfect!  This is my ideal – implementations happen quicker (saves money), with fewer problems (saves money, improves end-user perception), and are more secure (because of fewer interconnects between teams where problems can occur).

In most cases however, especially in big Corporates, IT teams are split in to silos and in my experience, they seldom play nicely together.  Who, for example, should look after a RADIUS Server?  “It’s a Server, so the Server team should” is the obvious answer, but it’s used by the Network team to secure the network and as it’s Cisco ISE or HP Clearpass it’s nothing the Server team know about so it’s now the network team’s responsibility.  Fine, networks it is.  But the RADIUS server will reference AD Group Memberships – who keeps these up to date?  What if the Server guys have a tidy up and delete some groups the RADIUS Server was using?  “The network  is down” come the cries from the office floor when nobody can get access, without the network guys having done anything wrong at all.  “Change Management will stop that from happening” is the common response, but “not always effectively enough” is my experience.  I’ve seen customers run siloed change control processes for example.  One Server guy talks to another Server guy about deleting some AD Groups.  Neither know about how the RADIUS Server uses the Groups so they get deleted and they break RADIUS.  Even customers that run sensible change control processes with all of the stakeholders involved, it’s still human nature to focus on what you’re interested in.  If the Desktop Team say they want to roll out a new AV Client, will the Network Team who are running Posture Assessment via Cisco ISE remember to implement new Posture Policies?  Not always.  When the network team rollout a new Secure SSID and ask the Desktop/Server Team to push out a new Policy to ensure Clients use the new SSID correctly and securely, does it always happen perfectly? Does it even happen at all?  Not always.  In my experience, Teams are too often guilty of an inwards looking mentality – “how can we help ourselves” instead of “how can we help the teams around us”.

In today’s ever increasingly integrated world of IT Solutions, I’m starting to think that strictly siloed working practices are borderline dangerous.  Sure, you’ll always need a specialist in one thing or another, but in my experience, the more people that have a nice wide end-to-end view of how “IT solutions” operate, the more usable and more secure – the better – the solution will be.  If everybody involved has a solution-wide view, far fewer things will fall between the gaps, leaving fewer issues for Users and fewer attack vectors for hackers.

Access Layer Security (Part 3) – 802.1ae

In previous entries we’ve looked at how easy it is to attack networks secured with Profiling, MAC Address authentication and/or 802.1X, especially if you have access to a device that is known to work.

So how then, if you can get around even EAP-TLS security on a LAN, do you really secure an Access Layer network?

802.1ae MAC sec

In short terms, 802.1ae is for wired networks, what WPA2 is for Wireless networks.

All of the methods of securing a network that we’ve looked at so far provide (varying levels of) authenticated network access, but do nothing to protect the traffic post-authentication, which, because MAC Addresses are so easily spoofed, potentially leaves big holes in your network’s security.

With MAC sec enabled networks and Clients, once the device has been authenticated through an EAP method (like PEAP or EAP-TLS), traffic is encrypted between the NIC of the Client and the Switchport, typically using GCM-AES-128 or GCM-AES-256.  Because the encryption negotiation process is secure, even if an attacker spoofs a MAC address and sniffs all of the traffic between a known good device and the network, they will not be able to decipher the encryption keys and they will not be able to gain access to the network.  This is, to my knowledge, the only way to guarantee (as far as anybody in IT can guarantee anything) that only valid devices can access the network.

Unfortunately, despite having been available for quite some time, support for MAC sec is somewhat limited.  There is currently no native support for MAC sec in Windows so Microsoft Users need a third party supplicant like the Cisco AnyConnect Agent.  MAC sec is supported in Linux though, from kernel 4.6 onwards (I think!).  802.1ae also requires a suitable Client NIC & drivers, and a LAN Switch and RADIUS Server that support 802.1ae.

Cisco Identity Services Engine (ISE) v2.4

Cisco Identity Services Engine v2.4 was released last week, bringing a number of changes to the platform.  The biggest changes to be aware of are;

VM Hosts are now licensed.

Previously the number of VM hosts deployed within a cluster wasn’t controlled.  Sure, Cisco asked you to buy a SKU for each VM ISE, but it wasn’t enforced by the appliaction until now.  With ISE v2.4, each ISE VM requires its own licenses and the licenses are specific to the size of the VM(s) you have deployed;

Small (<=16GB RAM, <=6 Cores)
Medium (16-64GB RAM, 7-8 Cores)
Large (>64GB RAM, >8 Cores)

If you’re planning an upgrade to v2.4 from an earlier release and you bought the proper VM SKUs, e-mail ise-vm-license@cisco.com with your order numbers and they’ll send you the licenses you need.  If you didn’t buy the correct VM SKUs, you’ll need to buy them from your Cisco partner first.

TACACS+ licensing change

Prior to v2.4, TACACS+ was a cluster-wide, on/off feature… you either had TACACS+ enabled or you didn’t.  From ISE v2.4 onwards, TACACS+ is licensed per PSN that you enabled TACACS+ on.

Larger VM MNT

A new ‘Large’ (huge!) VM appliance is available, specifically for the MNT role, significantly improving performance when it comes to the Live Log and Reporting.

Other enhancements

ISE v2.4 also brings a number of small enhancements;

  • Enhanced IPv6 support – Network Devices can now be defined with IPv4 and/or IPv6 addresses
  • Posture enhancements – Additional of a Grace Period and various enhancements to AnyConnect Posture module behaviour
  • Various TrustSec & pxGrid enhancements
  • ISE can now pull data from Cisco Industrial Network Director (Cisco IND)
  • Improvements to the profiler database

Personal view

There are some nice new features added in v2.4, particularly for those using Posture Assessment and those with larger estates, but I’d wait until the first Maintenance Patch or two have been released before deploying it in to a production environment.  If you can’t wait that long, do at least run it in a lab first and check it’s all fine and make sure you have a rollback plan in case there are any issues with it.

Further reading

Cisco ISE v2.4 Release Notes
Cisco ISE v2.4 Order Guide