Sunday, 25 August 2013

Configuring DHCP Option 226 on a Cisco Router/Switch for an Aerohive AP

There are a number of methods of directing an Aerohive AP to find its instance of HiveManager, including using a DHCP option.

In this quick tip, I share how to set up a Cisco switch or router DHCP server range to provide the correct  DHCP option to direct an Aerohive AP to a local instance of HiveManager. This is useful if you have a copy of HM running on your own appliance or virtual server.

APs may be passed the IP address of HM via DHCP option 226. In the example below, APs are assigned addresses in the range 192.168.20.0/24. The Hive Manager server may be found at 192.168.50.7 in this example.

The default router and DNS server options will need to be set to match your own environment.

!
! DHCP range for Aerohoive APs
! (HM address passed to AP using option 226)
!
ip dhcp pool APs
   network 192.168.20.0 255.255.255.0
   default-router 192.168.20.254
   dns-server 8.8.4.4
   option 226 ip 192.168.50.7

Hopefully, this is all fairly self-explanatory if you are familiar with IOS :)

Saturday, 24 August 2013

The Missing Feature in WiFi Solutions: Performance Testing

In this article I suggest a nice feature that would provide a useful WiFi vendor differentiation and a valuable tool for administrators of WiFi networks.

As a WiFi network value added re-seller (VAR) I visit a lot of customers, interacting mainly with the poor, down-trodden folks who comprise the IT department of an organisation. They are generally responsible for fending off the daily barrage of complaints about "the network".

In general, they are mainly concerned about two factors when it comes to their wireless network: coverage and performance. There are many other factors that they should probably be concerned about, but these are the two factors that tend to keep users off their back if they are both taken care of.

Verifying WiFi coverage for an average IT administrator is generally very simple. They simply do a Google search download a tool such as Metageek's inSSIDer and visit the area where users are complaining. Even if they don't manage to use dedicated tool such as inSSIDer, they will generally check the 'number of bars' displayed on a wireless client to get an idea of signal strength in an area. They will very quickly be able to determine if they have a coverage issue by verifying signal levels around a particular area.(Note: this isn't the only factor to consider, there may be other issues such as non-WiFi interference from security cameras, microwave ovens etc., but that's a discussion for another day). 

However, once coverage has been verified, then comes the more challenging issue of testing performance over the wireless network. The number one way I tend to see end users testing their WiFi network (especially on tablet or smartphone devices) is to fire up an app such as SpeedTest.net and verify the throughput to the Internet. Whilst this approach is easy to get a quick assessment of how throughout might look, there are a lot of holes in this approach, not least because it relies on both the bandwidth and current utilization of your Internet pipe. In many organizations, the results vary based on time of day (i.e. number of users on the Internet). It also provides no differentiation between the various components that the test data may traverse (i.e. wireless, wired and Internet).

There are several options that could be deployed by IT administrators, such as setting up an iPerf server somewhere on the network. They could then grab a copy of iPerf off the iTunes store or the Play store (Android) to do some throughput testing. However, I generally never see anyone using this approach, (I'm guessing as most folks don't have the time, knowledge or inclination to do it...).

For me, the answer is simple: WiFi vendors should build performance testing features in to their products.

Here are some high-level thoughts on how this might look: 
  • A server process along the lines of iPerf built in to each AP or controller
  • A reserved IP address (nominated at install-time) on each SSID (or even a hidden test SSID) for testing
  • A wireless-vendor created user app that could be downloaded from your favorite app store. This would allow IT admins to test the WiFi performance using various presets (e.g. voice/data etc.), taking away the complexity of the myriad of confusing options in tools like iPerf
Given the current processing power of the hardware of current WiFi solutions, how hard could this be!?!?

The benefits for IT admins of a feature of this type are enormous. It would certainly help to prove whether or not "its the wireless network", or whether the perhaps they need to look elsewhere. An approach like this would be a nice differentiator for a wireless vendor, as I'm not aware of anyone providing this kind of function integrated in to their solution (let me know if I'm wrong about this).

The marketing benefits of an app like this for a vendor are hopefully self-evident (brand awareness, targeted ads/messages). I suspect that the screen real-estate for WiFi testing tool vendors would be very appealing too - imagine the attraction of advertising to a user who is currently suffering a WiFi issue!

In addition, this type of functionality could be very useful to those of us perform wireless surveys,perhaps providing an easy method of  performing active surveys if an iPerf server was available as an integral function of WiFi infrastructure kit.

Well, that's my ten cents/pennies worth (depending on where you live). It would be nice to see a vendor implement something along these lines...anyone..? "Bueller, Bueller, Bueller....."

Update 25/08/13: Since posting this, I had some feedback on twitter from various folks (@revolutionwifi, @wifikiwi, @dszp) about some vendor products that have iPerf  (or similar test features).

I believe that Aerohive has iPerf available from the CLI on some of its products, Ruckus has the 'Zap' utility and Aruba has some form of client test utility. I don't get to use Ruckus or Aruba, but I'll be having a closer look at the Aerohive iPerf server.

Looking on the Apple app store, the Ruckcus 'Zapper' app looks very promising and is probably well worth checking out if you have a Ruckus network.

Despite these few items, the landscape for client testing across many vendors is still not exactly 'great' and these is a lot of work to do to enable end-users to easily evaluate their WiFi network performance.

Friday, 16 August 2013

How Much Air-Time Do Beacons Actually Burn?

It’s a well known rule of thumb when designing WiFi networks that you need to try to keep the number of SSIDs broadcast by your wireless network  down to a ‘reasonable’ number. In this article, I take a look at how much of an issue SSIDs (and their beacons) are in consuming valuable wireless air-time.

Generally, it’s recommended to keep the number of SSIDs below around 5 (ish).

The reason for keeping the number of SSIDs to a minimum is that each SSID is advertised using a type of management frame called a ‘beacon’.  Beacons are generally sent 10 times per second for each SSID on the wireless network. Therefore, if you have 10 SSIDs, they will each be advertised 10 times per second, giving us 100 beacons per second.

Air-time is a finite resource – there is only so much data that can be transferred across the air over a period of one second. If a large chunk of air-time is being consumed by SSID beacons, then that doesn’t leave a whole lot of time remaining for actual user data to travel over the air (which is the whole point of having a wireless network!).

I have previously heard statements from various wireless engineers along the lines of up to 50% of available air-time being consumed by beacons once you have 6 or 7 SSIDs being broadcast by a network. I’ve taken this information on face-value and never really thought too much about it.

However, this evening I found myself in a hotel room with some time on my hands, a Cisco WLC, a Cisco AP and a copy of Metageek Eye PA. I thought it was time to test the ‘conventional wisdom’.

My approach was simple: I would set up my AP on channel 11 (2.4GHz) and capture all frames using Eye PA. I would vary the number of SSIDs being broadcast and monitor the results.

I would also vary the lowest mandatory speed supported by the 2.4GHz network between 1Mbps, 11Mbps and 54Mbps. Beacons are sent at the lowest mandatory speed that is configured for a wireless network. Therefore, if 1Mbps is the lowest mandatory speed, beacons are sent at 1Mbps (and hence are a lot slower and consume more air-time)

To determine how much actual air-time is being consumed by beacons, I would use Eye PA’s filtering capabilities to remove all frames except beacon frames, and remove any other local interfering SSID traffic (i.e. the pesky hotel WiFi on the same channel!). This would leave me with just the beacon frames from my AP:

Eye PA Filtering Beacon Frame


Eye PA allows you to select a period of one second of the filtered traffic that you have captured, and also shows the amount of air-time those frames consumed in that period:



I just then applied some simple maths to work out how much time the beacons frames consumed over a period of one second.
I then tabulated the results:

Number SSIDs Broadcast
Lowest Mandatory Speed
Beacons AirTime Over 1 Sec (mS)
Percentage AirTime Used by Beacons
1
1Mbps
25
3%
7
1Mbps
167
17%
15
1Mbps
326
33%
1
11Mbps
10.5
1%
7
11Mbps
73.5
7%
15
11Mbps
158
16%
1
54Mbps
1.52
0%
7
54Mbps
10.6
1%
15
54Mbps
20.8
2%

The results show pretty much what I expected, but I was surprised by how little time the beacons consumed, particularly once the lowest mandatory speed is ramped up to 54Mbps. They certainly don’t support the information that had been imparted to me regarding 7 SSIDs consuming 50% of all air-time.

You can clearly see the effect of adding more SSIDs (and consequently more beacons). As more SSIDs are added, more air-time is devoted to beacon traffic. This is a bad thing, if it becomes a significant chunk of your air-time.

You can also clearly see the effect of increasing the lowest mandatory speed supported by the wireless network. Once you increase it to 54Mbps, even with 15 SSIDs, you are only consuming 2% of the available air-space.

I suspect that the conventional wisdom of keeping your SSID numbers down to below 5 is founded on the assumption that many wireless networks are going to be installed using default settings. Often, default settings will configure the lowest mandatory speed to one of the lower 802.11b speeds, which could then make significant numbers of SSIDs an issue.

For me there are several lessons to take away:

  • Verify what the defaults of a system are – what is the lowest mandatory speed configured on your system out of the box?
  • Increasing the lowest mandatory speed on a wireless network is going to increase the efficiency (and hence throughput) of your wireless network significantly – less time will be given over to beacon traffic
  • The ‘less than 5 SSIDs’ rule may be a good starting point, but on a well engineered network, it may not be as relevant as it used to do, especially in the presence of modern wireless clients which do not need to support the lower, legacy speeds of 802.11b/g.

A word of caution though before making any wholesale changes to your network. Make sure you do not have any older wireless clients that need to be able to connect to the network at the slower/legacy speeds. Clients need to be able to initially associate to a wireless network at the lowest mandatory speed supported by a wireless network. If you have older devices that are not in areas that have good coverage, they may not be able to associate at a higher speed and will not be able to join the wireless network in those areas. It is probably worth testing the effect of any changes you make carefully.


I’d welcome any feedback on my testing. If there are any flaws in my logic or testing or there are other considerations I may have missed, then please feel free to drop me a note or comment.

Wednesday, 14 August 2013

5GHz Unlicensed WiFi Channels in the UK - White Paper

(Note: this white paper has been superseded with this new updated version)

I put together a few articles a few months ago talking about how the unlicensed 5GHz band is used for WiFi here in the UK.

I thought it might be a good idea to consolidate all of the information that I found in to one place, so that people researching the topic could find and digest it more easily.

Therefore I put together a white paper about how 5GHz is used for WiFi here in the UK. You can download it from here.

There will no doubt be errors, omissions and other facts that folks would like to suggest. So, please feel free to drop me a note and I'll update this document from time to time to improve the quality of information that it contains.

Nigel.

Download the document from the following sources: