Multi-tenant wireless with Aruba MultiZone

The challenge with multi-tenanted environments.

One of the biggest challenges in a multi-tenanted environment is the ability to separate tenant data flows from one another. The problem is ensuring that you still provide a high level of security without having to encrypt every bit of traffic that traverses the network.

Do you deploy a single network and make use of the various flavours of virtual routing and switching technologies available on most enterprise networking products of today? While these technologies work great for the wired network, there traditionally hasn’t been too many options available in the wireless space.

This typically means that each tenant is left to deploy its own wireless network infrastructure regardless of how the wired network was setup.

Where does this occur?

• Shopping centres (with all those stores)
• Airports (with all those airlines)
• Universities (with all those departments)

Essentially, any environment that leases out its floor space to other occupants faces this challenge and it’s a bigger problem than you may realise.

Forget the additional infrastructure, deployment and management costs; as a passionate wireless engineer, I am concerned about the effects this has on your wireless performance!


One of the biggest limitations with the wireless medium (and you can blame the laws of physics for this one) is that it is a ‘shared’ medium. This means that on any given wireless channel, only one mobile device can be transmitting or receiving data at any given time. Each Wireless Access Point (AP) operates on a single channel per radio. There are mechanisms built into the wireless protocols that attempt to avoid collisions and retransmissions for these lightning fast transactions, so well designed networks shouldn’t experience a degradation in performance.

However, with a finite number of RF channels available for each AP radio and no control over what your neighbouring tenants are doing, the wireless medium can quickly become very congested. In fact, there is a laundry list of variables that effect wireless throughput, but I won’t go in to these here.

The solution – Aruba MultiZone!

Aruba have just released a long awaited software update on their Mobility Controller platform in ArubaOS 8.0. The release is one of the hottest topics within the wireless community right now. While it brings a number of very impressive features, MultiZone is definitely my favourite amongst the list, and is certainly a game changer.

What is MultiZone?

Aruba’s MultiZone architecture is built on top of their ‘mobile-first’ platform and allows multiple tenant independent wireless networks (SSIDs) to be created on a single set of APs while allowing each SSID and its associated data tunnels to terminate on separate customer owned Aruba Mobility Controllers.
You no longer need to deploy multiple networks to have multiple networks!

This solution not only separates tenant data flows using the same infrastructure, but it also allows a single Mobility Controller to manage things like the APs RF channel selection and transmit power levels allowing complete control over the wireless medium. While each tenant can completely manage their own wireless networks, they have no control or visibility of those settings that could have negatively affected the wireless experience for everybody in the vicinity using solutions of the past.
MultiZone is also a great solution for ‘guest’ wireless networks too! Corporate or trusted networks can terminate on a controller hosted within your internal network, while the guest network terminates on a controller hosted within your DMZ ensuring your corporate wireless data is safe and secure.

Head over to Aruba and check out the rest of the mobile-first platform.

Article originally posted here

A Brief History of WiFi

Although the first wireless networking specifications and standards were released in 1997, the technologies that comprise the WLANs of today have a long history that can be traced back to the 1800s.

The estimated number of WiFi enabled devices in use today is estimated to be close to 7 billion! With that said, it's easy to understand why WiFi is considered one of the greatest technology inventions in modern history. Could you live a day without your smartphone, tablet or laptop?

The table below listed the key dates and their significance in the evolution of WiFi. I purposly began the adventure at the discovery of Electromagnetic Waves as to not go down the rabbit hole that could include half of science!

See my previous post for a summary of IEEE 802.11 PHY Standards.

802.11n + 802.11ac data rates and SNR requirements

When designing a wireless network that requires very high data rates per client device, it is critical that you understand what conditions need to be met in order for the client devices to hit those rates (maybe a post for another time).

At the end of the day it comes down to one factor: A higher Signal-to-Noise Ration (SNR) will produce a higher data rate.

I have two sites bookmarked in my web browser to remind me of those requirements.

http://www.revolutionwifi.net/revolutionwifi/2014/09/wi-fi-snr-to-mcs-data-rate-mapping.html

and

http://mcsindex.com/

Both authors have obviously done an incredible amount of research to gather the data so I absolutely in no way pretend to have put together this myself. The Receive Sensitivity/RSSI requirements have been compiled from various sources and should only be used as a guide as each vendor radio will have their own specifications.

Anyway... I got tired of flicking between the two sites above so I decided to create a chart that merges the two. It has become my one stop shop for quickly determining the SNR requirements for a required throughput (I lie, there are two charts, one for 802.11n and one for 802.11ac.)

I recommend having a read of the first post. Andrew Von Nagy has done an amazing job on explaining the how MCS rates are achieved...

802.11n

 802.11ac

For those that don't have the ability to download the images in HD; I have provided a link to the original excel document - 802.11n/ac data rates and SNR requirements

I welcome all feedback!

-Brett

Cisco Patch Antenna and Cabling Configurations

When you make the decision to use a Cisco patch antenna for use on an AP model that requires external antennas, choosing the correct antenna and cabling accessories to do the job can be a bit of a daunting task.

You will still need to perform a site survey to determine which AP will meet your density, performance and coverage requirements, but you need to make sure the antenna is compatible with your AP! 

Typically your Cisco Sales Rep will know what parts connect to what, but it is always handy to know what your options are.

I don't deploy outdoor APs or indoor APs with external antenna connectors too often, so when I do I often forget what I can and can't do in this space. 

I created the images below to remind me quite some time ago, however have recently updated them with the latest Cisco AP models.

Please let me know if anything is incorrect!

IEEE 802.11 PHY Standards

The IEEE 802.11 standards used by the Wireless LANs of today have seen many amendments since first being published in June 1997. These amendments address the ever-growing demands put on the wireless medium due to the the onslaught of mobile devices and the need for wireless performance to be on par with the wired network.

The image below summarises the key 802.11 PHY protocols, which have a primary goal of increasing throughput to the wireless client device;

I will keep this table updated as new standards are ratified. In a future post I will list all 802.11 standards and amendments.

-Brett

Cisco WLC Discovery & Join Methods

In the Cisco Unified Wireless Network (CUWN) architecture, a Wireless LAN Controller provides central configuration and management of Cisco Lightweight Access Points. A Lightweight AP simply cannot cannot operate independently and must join a controller before it can can start to serve wireless clients.  An AP will use a number of methods to discover a list of controllers and their configured management IP addresses before it decides which one to join.

DISCOVERY PROCESS

Upon connecting an AP to the network, the following WLC discovery methods will be attempted:

1. Broadcast on local subnet
2. Use a previously configured/discovered list stored on the APs NVRAM
3. Use DHCP Option 43 provided from DHCP server
4. Use DNS to resolve "CISCO-CAPWAP-CONTROLLER.localdomain"

Broadcast

The AP will send a CAPWAP Discovery Request message on the local subnet. Any controller that has a management IP address within the same subnet will respond and can be used by the AP.

If there are no controllers located in the same subnet, the router can forward broadcasts (in the form of unicast packets) to the controller. The CAPWAP Discovery Request message is sent on UDP 5246.

Via IOS CLI:

ip forward-protocol udp 5246
interface <interface_name>
     ip helper-address <wlc_ip_address>

NVRAM

This list is built from a number of sources:

• Previously configured Primary, Secondary & Tertiary controllers

Via WLC GUI:

Via WLC CLI:

config ap primary-base <wlc_name> <ap_name> <wlc_ip_address>
config ap secondary-base <wlc_name> <ap_name> <wlc_ip_address>
config ap tertiary-base <wlc_name> <ap_name> <wlc_ip_address>

Via AP CLI:

config ap controller ip address <wlc_ip_address>

• Controllers part of a previously joined Mobility Group

DHCP Option 43

DHCP Option 43 is a vendor specific option which the Lightweight APs can also use to locate a controller. The controllers management IP address is entered in hexadecimal in the form of: Type + Length + Value, where;

Type = Always sub code option - 0xf1 (expressed as f1)
Length = Number of controller management IP addresses specified, multiplied by 4.
Value = IP addresses of controllers, listed sequentially

Via IOS CLI:

ip dhcp excluded-address <start_ip <end_ip>
ip dhcp pool <pool_name>
     network <ip_address> <netmask>
     default-router <gateway_ip>
     dns-server <ip_address1> <ip_address2>
     domain-name <domain>
     lease <days> <hours>
     option 43 hex <hex_value>   // e.g. option 43 hex f104.0a5e.dec8

Via Windows Server:

DNS

The AP will attempt to resolve "CISCO-CAPWAP-CONTROLLER.localdomain" to an IP address. This can be done by configuring a Host A Record on the DNS server specified in DHCP.

JOIN PROCESS

Once the AP has built a list of possible controllers, it will attempt to join one of them using the following order:

1. AP's NVRAM configured Primary controller
2. AP's NVRAM configured Secondary controller
3. AP's NVRAM configured Tertiary controller
4. Least loaded controller learnt through dynamic methods (broadcast, DHCP option 43, DNS)

Once an AP has joined a controller it will forgot about the controllers learnt through the dynamic methods listed in number 4 above.

If an AP is joined to a controller, and that control fails, the AP it will attempt to join another controller using the order below:

1. AP's NVRAM configured Primary controller
2. AP's NVRAM configured Secondary controller
3. AP's NVRAM configured Tertiary controller
4. WLC's Backup Primary controller
5. WLC's Backup Secondary controller
6. Controllers part of the WLC's mobility group membership

If an AP cannot join one of the controllers above, it will reboot and start the re-initialise the discovery process.

VERIFICATION

To confirm what controllers the AP is currently aware of, there are several AP CLI commands available:

show capwap client config



 // LIST OF NVRAM CONFIGURED WLCS (PRIMARY, SECONDARY, TERTIARY)

mwarName                WLC1
mwarIPAddress           10.100.5.1
mwarName                WLC2
mwarIPAddress           10.100.5.2
mwarName                WLC3
mwarIPAddress           10.100.5.3


// LIST OF WLCS IN PREVIOUSLY LEARNT MOBILITY GROUPS

Configured Switch 1 Addr 10.100.5.1
Configured Switch 2 Addr 10.100.5.2
Configured Switch 3 Addr 10.100.5.3
Configured Switch 4 Addr 10.159.44.17
Configured Switch 5 Addr 10.159.44.18

show capwap client ha

// LIST BACKUP PRIMARY & BACKUP SECONDARY WLCS (LOCAL TO CURRENT WLC

primaryBackupWlcIp      10.100.5.2 
primaryBackupWlcName    WLC2
secondaryBackupWlcIp    10.100.5.3 
secondaryBackupWlcName WLC3

802.11 EIRP limitations in Australia

I have recently had the opportunity to design and implement an outdoor wireless mesh network at one of Australia's major airports. Although relatively straight forward to implement, we had challenges in deciding what channels to use on each Root Access Point (RAP). A spectrum analysis of the required locations (highly secure) wasn't in scope so we relied on Cisco's Clean-Air reports to tell us the least used channels in each location once the APs were installed.

Without going in to details it turns out that the 5GHz band at airports (or at least this one) is quite utilised and we couldn't just randomly assign the UNII-3 channels available to us. In order to provide a fast, yet stable network we had to choose a channel which had the highest consistent Signal-to-Noise Ratio (SNR) for each RAP. Some channels had a higher 'peak' SNR but would occasionally drop to an unusable level.

This was the first time I had to REALLY think about neighbouring WiFi networks and the potential performance impact I could impose on those networks (as well as my clients) by not planning carefully. It was also the first time I had to care what the transmit power laws for the 2.4GHz / 5GHz bands in Australia were. After all, I would hate to be responsible for a plane to drop out of the sky!

Technically a Wireless LAN Controller will limit an AP's Effective Isotropic Radiated Power (EIRP) to the limits of the regulatory domain that the AP is based in. However a WLC trusts that you have provided it with antenna gain values that match the ACTUAL gain of the antennas you are using. Entering a gain value that is lower than the real value could cause the WLC to use a higher transmit power on the AP's radio, potentially violating the laws of the domain.

Getting to the point of this post...

This got me thinking about what the EIRP laws for Wireless LANs are in Australia. Although the ACMA (Australia's version of the FCC or ETSI) and the ComLaw websites do provide the information, the sites aren't exactly intuitive or display the information in an easy to view manner, so I have created a chart that does exactly that (see below). There is still talk of the ACMA following the FCC and adding various other laws around the use of the 5GHz spectrum, but as far as I can tell these are not actually in place as of yet, so I have left these out of the chart.

Feel free to use to graphic as you please. All I ask is that the (c) be retained. I will update the chart as changes are made to the bands or the the laws are modified. I would love some feedback if you feel something needs to be corrected :)

-Brett