Connecting the world…


Flash clean-up

Lately I upgraded a Aruba Networks wireless controller or at least I tried…… The upload of a new image to the controller has two steps. First the copy process from a TFTP server to the controller and second the actual writing of the new firmware image to flash (system partition). The second step kept showing me exclamation marks for minutes. I left it running for one hour and finally decided to break the upload by ending the SSH session and starting a new SSH session. I wasn’t able to connect to the controller via SSH and physical access via the console didn’t work either. So I decided to reboot the controller via the hard reset. The controller rebooted the old system partition, but I noticed that the new system partition was imported and digitally signed (check via: show image version).

I changed the boot parameter to boot the new software and rebooted the controller. I received the following error message on the console after the reboot.

Ancillary image stored on flash is not for this release
* WARNING: An additional image upgrade is required to complete the *
* installation of the AP and WebUI files. Please upgrade the boot *
* partition again and reload the controller. *

I decided to upload the firmware a second time to the same system partition, but this time the controller “told” me that there wasn’t enough free space on the flash drive so I couldn’t copy the file. I noticed that I only had 35M flash storage left (check via: show storage).

I deleted some files from flash (via command: delete filename <file name>), but I couldn’t free enough space to copy the image a second time. Finally I used the tar command to clean up enough storage. The tar command archives a directory and creates a tar file in the flash memory, which can be deleted. The syntax is:

tar clean {crash|flash|logs}| crash | flash | logs {tech-support|user}}

I ran the commands:

tar crash
tar flash
tar logs.

This creates three separate files in the flash memory. The files can be deleted via the commands:

tar clean flash
tar clean logs
tar clean crash

After running these commands I had113.3M flash storage available, which is more than enough to copy the new firmware a second time to the system partition.

In my situation the crash files were the reason I didn’t have enough flash memory. Because I did a hard reset the controller created a lot of crash files, which are stored in flash memory.

Wireless controllers – the discussion continues

There is already a lot said and written about wireless controllers and it’s architectures. During my recent holiday my thoughts were wandering about this subject. At the beginning we had the stand-alone access-points, which were all configured as unique identities. Choosing the correct channel and power level could be a challenge in dense environments, so everybody was happy with the centralized wireless controllers.

The centralized wireless controllers were the solution to manage channel and power allocation with their build in ARM functionalities. But also the centralized management of the entire wireless environment was a great improvement for the management burden of IT personnel. Key players, like Cisco Systems and Aruba Networks, adopted this architecture and developed some outstanding wireless controllers. Over time more and more feature were added to the controllers, like spectrum analysis, wireless intrusion prevention systems, L3 roaming and advanced reporting. For some features you have to buy a separate license or you should use dedicated software or hardware, but nonetheless you have a easy to manage and flexible wireless design.

Some people started to discuss this architecture and found some disadvantages, like availability and scalability. The access-points are all managed by a centralized wireless controller, but what happens if the controller goes down? Who much time does it take to failover to a backup wireless controller? What license construction do I need when I would like to implement a redundant wireless controller architecture? Why do I need to tunnel all traffic from the access-points to the wireless controller, before the data of wireless clients accesses the wired infrastructure? Isn’t this a disadvantage for latency, delay and jitter characteristics? What is the impact for the controller when tunneling all traffic and who can I scale the controller to the future? These are all valid questions and some vendors decided to develop another wireless architecture.

Maybe the most well-known is AeroHive with their controller less wireless architecture. The wireless controller functionality is integrated in the access-points, but the management is still centralized. Every access-point is operating as an autonomous entity, but all access-points communicate with each other to form a hive (in AeroHive terminology). All configuration and monitoring is done through a centralized management platform. The impact of access-points loosing their connection with the management platform is minimal. The access-points stay online and stay operational for wireless purposes. This means that the wireless environment doesn’t depend on one or more wireless controllers.

But is this the most ideal situation……. not in my opinion. A few weeks ago a customer couldn’t’ access this manager for a couple of days. No problem, because the wireless infrastructure kept working like a charm. However the customer wasn’t able to do any kind of management and monitoring. He couldn’t see what was happing on his wireless LAN and he couldn’t add additional guest users to the AP user database. The question at that moment was: “Do we keep using the wireless infrastructure without any kind of monitoring and management with all risks associated or do we physically shut down the wireless network by disabling the PoE on the switch ports?”

There are some more “disadvantages” for a controller less architecture. VLAN extension (to a remote location) is difficult. This can be accomplished by configuring GRE tunneling between the remote AP’s and the HQ AP’s. With GRE tunneling you can extend the corporate VLAN to remote locations. The remote AP is the source of the GRE tunnel and the HQ AP is the destination. Another topic is RADIUS authentication. In a controller less architecture every AP acts like a RADIUS client. This can have impact on your RADIUS server. For example a Windows Standard server has a limit of 50 RADIUS clients. This means that you have to use a Microsoft Enterprise or Data Center server. You can also configure RADIUS proxy on the wireless environment. This means that all RADIUS from the AP’s are routed to the a couple of designated AP’s, which act as RADIUS proxy. You should also keep in mind that all traffic is directly routed to the wired network at the access-point. If you are using different VLAN’s, you shouldn’t forget to tag this VLAN’s on the uplink connections to the access-points.

I was talking about disadvantages. The topics aren’t real disadvantages, but more design issues. The point that I am trying to make, is that even a controller less architecture is sometimes working as a controller based wireless architecture. Because building GRE tunnels from remote locations to central AP’s or using AP’s as RADIUS proxy behaves, in my opinion, as a controller based environment.

So the discussion of a controller based architecture, a controller less architecture with a separate manager or a controller less architecture with a virtual controller will continue and every vendor will be saying that his solution is the best. I am very curious about your thoughts on the different wireless architectures.

Please keep in mind, this article is based on my experience and opinion. Also note that I am NOT saying that the solutions of the different vendors aren’t good choices to build your wireless network. I am using and will be using the solutions from the mentioned vendors in this article. Every solution has its advantages and disadvantages. Just look at the requirements for your wireless networks and choose the best suitable solution.

Cisco WLC – Upgrade FUS image

Today I upgraded a FUS image on a Cisco WLC 5500 controller, because I also upgrade the WLC software to The FUS upgrade is straightforward and comparable to a regular software update. The only difference is that you need console access to perform the upgrade. The FUS image upgrades the following components:

  • 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

During the upgrade process you have to confirm to proceed the upgrade, like shown below

Checking for Field recovery image upgrade

Field Recovery Image upgrade …

        Upgrade Field Recovery Image from version to

        Are you sure you want to proceed (y/N) ? y
* Please make sure POWER SUPPLY is always ON during this period. *    ******************************************************************

Erasing Flash (estimated 49 seconds) …

Writing to flash (estimated 716 seconds) …

This happens multiple times and the controller reboots several times during the upgrade. It took about 20 minutes for the complete upgrade of the FUS image.