Friday, 11 December 2015

High Density Wi-Fi SSID Considerations – Part 1

Typically within very high density WiFi deployments we recommend a having a low number of SSIDs particularly in the 2.4 GHz spectrum. We may want to have fewer SSIDs in the 2.4 GHz spectrum than in the 5 GHz spectrum. This is due to the available airtime slots within each specific spectrum. Within this blog  try to explain over a few parts in detail the cause and effect of the performance impact of multiple SSIDs within a high density WiFi environment. It will also help to illustrate the importance of a WLAN Policy within the high density WLANs to manage rogue devices and interferers.

In any WLAN environment we have management traffic and control traffic as well as our client data. This management traffic creates an overhead that has an impact on the amount of airtime that we actually have available to send data which is what we built the WLAN for in the first place. The lower our management and control overhead the more airtime we actually have to transmit data. The trade-off is that without the RF management and control traffic we would not have a WLAN to transmit data in the first place but we can take steps to limit this and claw back some of that valuable airtime. If we do not control it we can see very high channel utilisation and saturation with just management traffic and severely degraded WLAN performance. 

Generally speaking the most prevalent management and control traffic will be beacons, probes and probe responses which is where we focus this discussion for having a low number of SSIDs particularly in 2.4GHz and tools which we can use to mitigate the issues within the Cisco portfolio
Equally the reason we focus on 2.4GHz is that it is by far the most difficult use case with the prevalence of interferers, the lower number of channels and its higher signal propagation.

In the 2.4 GHz spectrum we have only 3 channels as compared to typically 16 to 20 in 5GHz (depending on your regulatory domain etc), the reason we discuss 12 channels in 5GHz particularly. Therefore we have significantly less available airtime if we were to have an equal number of devices in 2.4GHz as we would in 5GHz. 

Typically we are seeing a shift of devices to the 5 GHz spectrum which alleviates a lot of the pain as we have approximately only a fifth of the capacity in 2.4 GHz as we do in 5 GHz or less now with the improved efficiency of 802.11ac.



Defining High Density Wireless

HD Wi-Fi has become de riguer over the last two years or more and no doubt there will be another flavour of the month soon. The reality of HD Wi-Fi as a feature is different in that it is intangible without an easily definable outcome. Usually a solution will either work or not work, however when you are looking to deploy HD Wi-Fi not all vendors are equal, be that due to the chipset, the features or product portfolio.

For example if you deploy EAP-TLS, bonjour guest access or multicast you have either standards based protocols to work with or a clearly defined goal. The issue is one mans high density is another mans normal density.

People often say they need "high density" and ask if the proposed solution can do "high density". My immediate response is “lets define high density” rather than “of course it can everyone's WLAN solution can do high density”.

High density WLANs, like everything else, can only be tested once installed and tested againstthe design brief. If there is no design brief as to how many clients, what type of clients and what type of applications you are simply unable to measure the success or lack thereof of your implementation. So you must absolutely define how many clients etc you will support.

Lets take a look at what two different people deem as high density Wi-Fi

Option 1 - A WLAN deployment in a busy office with lots of people for voice, video and data where you might get 40 clients per access point and each access point is using omni directional antennas may be described as high density. It certainly is higher than perhaps a normal enterprise WLAN density nad as such may be defined as high density.

On the other hand

Option 2 – A stadium where you have 90000 people and each access point covers 400 seats to provide data, video and location.

Option 1 there is a moderate expectation that you will be successful with many vendors, some more successful than others. I respect that this is not that far away from a pretty standard deployment and most enterprise class WLANs should be able to cope with this. 

Lets define the high density environment as 20 seats per cell and 3 devices per seat so we have a maximum design of 60 devices on an access point. 

Simply by defining the expected outcome if you have 61 devices and the WLAN fails you have exceeded the design. OK we need to define in more granularity the applications per cell etc so we do not end up with 60 voice clients but our expectation would be a sensible split of clients and applications. 

This would provide a reasonable user experience for typical office based applications.

Option 2 where we have a stadium typically we would define the total number of clients we could reasonably expect to have on the WLAN simultaneously at any one time. For this example lets assume 25%. We need to use directional antennas to segregate the RF and we want location and video as well. 

Next step is to define the video capabilities and start to manage the customer expectations that it may not work well in all areas. Additionally with location we will not see the granularity that we could expect in an environment that lends itself to a location based deployment.

The requirements in the eyes of the customer are both high density Wi-Fi however the approach, expectation and usage are both very very different and need to be managed differently. Indeed not all vendors would be able to provide a solution for option 2 as very high density WLANs pose many different challenges that you will only see in that type of environment. More vendors perhaps have the capability to solve the challenges of option 1.

Are they both high density or is one simply an extention of the success of Wi-Fi and the growth of devices in the market place and new standards like 802.11ac. All of this coupled with client and user expectation that Wi-Fi is very much commoditised these days means we will always have challenging situations where our Wi-Fi skills and ability to communicate designs successfully will be tested.

What will the next flavour of the month be?

Friday, 10 February 2012

WLC FUS

This is the first time I have seen Cisco WLC FUS (Field Upgradeable Software), its very much like the old bootloader versions and something you should apply if needed. It is only for code version 7.2.10.3.0 at the present time however there may be future versions, I guess we will have to wait and see.

Field Upgrade Software (FUS) is a special AES package that performs various system-related component upgrades. We recommend that you install FUS to upgrade components such as the bootloader, field recovery image, FPGA/MCU, and other firmware to their latest respective versions.

--------------------------------------------------------------------------------

Note On a Cisco 5500 Series Controller, it is observed that the controller sporadically reboots and displays the following FPGA error message:

fpga: Lost heartbeat from Environment controller, system will reboot in 5 seconds!!!

A crash file is not created to debug or troubleshoot the error.
You can resolve this issue by installing FUS.

--------------------------------------------------------------------------------

The table lists the components that are upgraded after you install Field Upgrade Software for various controller platforms.

Components Upgraded 

Controller Platform
Components Upgraded

Cisco 5500 Series Wireless Controllers

•Field Recovery Image is upgraded to runtime image version

•Bootloader is upgraded to 1.0.16

•Offline Field Diagnostics is upgraded to 0.9.28

•FPGA Revision version is upgraded to 1.7

•Environment Controller (MCU) Image version is upgraded to 1.8

•USB Console Revision version is upgraded to 2.2

Cisco Wireless Services Module 2 (WiSM2)

•Field Recovery Image is upgraded to runtime image version.

•Bootloader is upgraded to 1.0.16

•Offline Field Diagnostics is upgraded to 0.9.28

•USB Console Revision version is upgraded to 2.2

Note Due to a software issue, the FPGA does not get upgraded in a WiSM2 controller even though the console output indicates that it has been upgraded.

Cisco Flex 7500 Series Controllers

RAID firmware


Note You must install FUS only if you do not have the versions of the components mentioned above.

Thursday, 9 February 2012

Cisco NCS Deployment

Having deployed the Cisco NCS a few times now I thought I would add a post outlining the steps to get it up and running. Its a little more difficult that the WCS and seems to take a little longer to get up and running. Hopefully this may help one or two people. This relates to the virtual appliance.

The minimum server requirements are available via the datasheet but once you have your hardware and software you are ready to rock. There really is nothing that complicated however make sure you do meet the server requirements for your deployment. If you do not have enough memory, like the first deployment I did, it can be problematic and take a looooooong time to install.

Something to point out is that you need to start the server after the installation, simply use the command "ncs start"

Below are typical screens presented during the NCS implementation

From the VMware vSphere Client main menu, choose File > Deploy OVF Template. The Deploy OVF Template Source window appears:



Choose Deploy from file and choose the OVA file that contains the NCS Virtual Appliance distribution.

Click Next. The OVF Template Details window appears. VMware ESX/ESXi reads the OVA attributes. The details include the product you are installing, the size of the OVA file (download size), and the amount of disk space that needs to be available for the virtual machine (size on disk).

Verify the OVF Template details and click Next. The Name and Location window appears



Either keep the default name for the VM to be deployed in the Name text box or provide a new one and click Next. This name value is used to identify the new virtual machine in the VMware infrastructure so you should use any name that distinguishes this particular VM in your environment.The Host / Cluster window appears



Choose the destination host or HA cluster on which you want to deploy the NCS VM and click Next. The Resource Pool window appears.

If you have more than one resource pool in your target host environment, choose the resource pool to use for the deployment and click Next. The Ready to Complete window appears.

Review the settings shown for your deployment and, if needed, click the Back button to modify any of the settings shown.

Click Finish to complete the deployment. A message notifies you when the installation completes and you can see the NCS Appliance in your inventory.

Click Close to dismiss the Deployment Completed Successfully dialog box.

In the vSphere Client, click the NCS Virtual Appliance node in the resource tree. The virtual machine node should appear in the Hosts and Clusters tree below the host, cluster, or resource pool to which you deployed NCS Virtual Appliance.

On the Getting Started tab, click the Power on the virtual machine link under Basic Tasks. The Recent Tasks pane at the bottom of the vSphere Client pane indicates the status of the task associated with powering on the virtual machine. After the virtual machine successfully starts, the status column for the task displays Completed.

Click the Console tab, within the console pane to make the console prompt active for keyboard input.

At the login Prompt, enter setup.



The NCS configuration script starts. The script takes you through the initial configuration steps for NCS Virtual Appliance. In the first sequence of steps, you configure network settings.

As prompted, enter the following settings:

Hostname for the virtual appliance.
IP address for the virtual appliance.
IP default subnet mask for the IP address entered.
IP address of the default gateway for the network environment in which you are creating the virtual machine.
Default DNS domain for the target environment.
IP address or hostname of the primary IP nameserver in the network.

At the Add/Edit another nameserver prompt, you can enter y (yes) to add additional nameservers, if desired. Otherwise, press Enter to continue.

NTP server location (or accept the default by pressing Enter). At the Add/Edit secondary NTP server prompt, you can enter y (yes) to add another NTP server. Otherwise, enter n (no) to continue.

Enter the username for the user account used to access the Cisco NCS system running on the virtual machine. The default username is admin, but you can change this to another username by typing it here.

Enter the password for NCS. The password must be at least eight characters and must include both lowercase and uppercase letters and at least one number. It cannot include the username or default Cisco passwords. After you enter the password, the script verifies the network settings you configured. For instance, it attempts to reach the default gateway that you have configured.



After verifying the network settings, the script starts the NCS installation processes. This process can take several minutes, during which there is no screen feedback. When finished, the following banner appears on the screen:

=== Initial Setup for Application: NCS ===

After this banner, it starts with database scripts and reboots the server as shown in the console:

Running database cloning script...

logger: invalid option -- l
usage: logger [-is] [-f file] [-p pri] [-t tag] [-u socket] [ message ... ]
Running database creation script...
logger: invalid option -- l
usage: logger [-is] [-f file] [-p pri] [-t tag] [-u socket] [ message ... ]
Setting Timezone, temporary workaround for DB...
Generating configuration...

Rebooting...


Log in as admin and enter the admin password.

Exit the console using the exit command.

Enter the following command to start the NCS Server.

ncs start

CCNP Wireless - IAUWS

Well I sat and passed the IAUWS exam today, thats the security part. I am pushing hard to complete version 1 of the CCNP Wireless as I have some study materials available and I have been studying on and off for about a year. The only reason I haven't actually taken any of the exams is time.

This exam was a bit of a suprise. The exam blueprint is a great starting point which is available here but I was suprised how much focus there was on wireless NAC. Not an easy exam and you really need to read the documents. Some of the questions, as in any exam I guess were really straight forward but there were that were difficult to understand.

A great deal of material to cover and some tricky areas. A great test though.

Monday, 6 February 2012

802.11ac update

I briefly mentioned 802.11ac a while ago here however a little more information is now available. At CES this year some vendors demonstarted 802.11ac products. Notably Buffalo with a prototype running a Broadcom chipset. Although this had a mighty 800mbps throughput that really is the tip of the iceberg.

A few highlights.
  • 802.11ac should be backwards compatible with 802.11a/n.
  • Channel widths will be 80 or 160MHz (802.11n can use 40MHz wide channels) now it remains to be seen exactly which channels these will be and how that can be worked into the current regulatory domains around the world.
  • Support for 8 spatial streams compared to 802.11n 4 spatial streams. If like 802.11n initial products wont be the full bore 8 spatial streams however and similarly to 802.11n that may be a theoretical maximum, nobody has commercialised a 4 spatial stream device and there are only a few vendors with 3 spatial stream access points.
  • A massive 256 QAM against 64 QAM for 802.11n.
  • There will be compatability mechanisms for 802.11ac to coexist with 20 and 40MHz 802.11a/n
  • Lets not forget MU-MIMO which will let us have multiple devices receiving from a single signal.
  • Ultimately we all want to know how fast, well 6.93Gbps.
I feel it will certainly speed up the adoption of the 5.0GHz technology, I only hope it does not become as congested as the 2.4GHz spectrum however this may be the leading technology of the future so simply it will be everywhere, consumer electronis included. That will present its own challenges again as we try to support a greater level of legacy devices.

It certainly bodes for an interesting future as a wireless engineer.

Friday, 3 February 2012

CCNP Wireless - CUWSS

Finally sat down and took the first of my CCNP Wireless exams, and passed.


OK its generally agreed that this probably is not the hardest of the CCNP exams but there are a few questions that could trip you up. Even if you do a lot of surveying there are areas that you will need to know with respect to the WCS planning tool and Cisco Spectrum Expert.


Now I admit that I do not use these tools every day so I spent a little time on WCS and read through the Spectrum Expert stuff.


The Quick learning guide from Cisco Press was great as any areas I was not 100% on I done a little studying.


It probably helped iron out any wrinkles I had as well in best practices etc.


Overall pretty straightforward if you know your stuff.


Already booked IAUWS for later this month and started reading the Quick Learning Guide, I must say there are a few more grey areas than there were for the CUWSS as there are a few things you dont work on often, and some not at all so onwards and hopefully upwards.

High Density Wi-Fi SSID Considerations – Part 1

Typically within very high density WiFi deployments we recommend a having a low number of SSIDs particularly in the 2.4 GHz spectrum. We m...