Posts

Showing posts from 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 :)

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 to…

How Much Air-Time Do Beacons Actually Burn?

Image
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 trav…

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:
ScribdGoogle Docs