Recently, while getting some bids for a home construction project, one of them came back with a dollar figure coupled with this caveat: ‘Bigger than a bread box, smaller than a submarine.’ I see this same kind of concept practiced with wireless capacity planning at a lot of the companies that see on a day to day basis.

Why do so many IT departments follow this planning philosophy?

Well, it boils down to not having the reporting and visibility required to make good business decisions to maximize the IT budget.

Over the last year, I have done several webcasts around capacity planning and wireless best practices. Most of these have focused around the wireless side of the equation, but as wireless becomes more ubiquitous, there is now the requirement to look at other pieces of the puzzle as well. Take for example the wireless hotspot marketplace. Many of these locations are served with DSL or cable modem access. Remote office locations are also typically served by these types of links as well. In this case, what component is the weak link in the chain? Of course, the WAN link is the limiting factor!

In the latest version of the AirWave Management Platform, there is now the ability to monitor and report on switches, routers, and other gear in the network that can impact the wireless network. In addition, there is a new Capacity Planning report that not only shows the capacity of the wireless APs and controllers, but can also show capacity available on other network components as well.

In the ‘Troubleshooting the WLAN’ webcast that I did earlier this week, I talked about the technical items that the helpdesk really needs to know to move from a ‘Production Metric’ helpdesk to a ‘Customer Service’ helpdesk. The helpdesk industry over the last decade has really moved from being an organization that is geared around hold times, abandonment rates, tickets opened, calls received, and other production metrics to an organization that starts to value the ‘softer’ side of the call center.

These ‘softer’ customer service metrics are geared around first call resolution, reopened ticket percentage, and other items that revolve around how the caller feels about the experience, rather than just how fast the helpdesk can pick up the phone. If we look out at the IT industry as a whole, there have been several recent examples of large IT companies who forgot that customer satisfaction is just as important as how fast you answer the phone! Now, those companies are paying for it with reduced sales, a falling stock price, and erosion of their corporate brand value.

So, to take this down from an overall corporate view and apply it to the wireless helpdesk, what do we need to give to our front line employees to improve their customer service metrics? Well, it boils down to giving them the applications to solve problems immediately, and if they can’t be solved at their level, the ability to escalate to the proper team for a quick resolution.

In the wireless space, it’s all about letting the helpdesk view real time user information, visually displaying RF information in an easy to read format (remember, the helpdesk is not staffed with RF engineers), trending information (see my earlier blog on ‘Troubleshooting Deltas’), and other troubleshooting dashboards. This way, the helpdesk can accurately diagnose the problem and either fix the issue, or get the trouble ticket to the correct place in the least amount of time.

Once the helpdesk is able to start focusing on the ‘softer’ side of their business, the user satisfaction rates will go up and the ROI of the wireless network starts to really take hold.

 

 AirWaves Podcast with Manatee Schools [20:42m]: Play Now | Play in Popup | Download

In this latest installment of AirWaves, I spoke with Ron Jones who is one of the Network Systems Managers for Manatee County School District, one of the largest in the country with over 49,000 students and 7,000 employees.

Like most school districts, the wireless network at Manatee has grown over time. Manatee CSD now has about 2,000 wireless access points from Cisco and ProCurve by HP and serves up wireless access to just about every campus in the district.

As you can imagine, Ron has his hands full and has found ways to use his AirWave Management Platform to streamline many of the manual processes.

At AirWave, people constantly ask us “Why is it important to select a vendor-neutral wireless management solution if I have an ‘all-Cisco’ [or all-Aruba, all-Symbol, all-Anyone…] network?”

A few things to consider:

• You might have a heterogeneous network and not even know it — In large organizations, the left hand often doesn’t know what the right hand is doing. Is it possible [likely?] that a division somewhere in the world purchased some equipment that you don’t know about? If you use only proprietary single-vendor management tools that only discover APs and controllers manufactured by your primary hardware vendor, you may never find out — and if you do have some other equipment out there, you won’t be able to manage it and enforce your security policies using your proprietary tool.
• Wireless technology is still evolving — and so are wireless product lines. WiFi is so ubiquitous that people forget that the technology is still young. Many new technologies and standards [802.11n, anyone?] are still being developed. Hardware vendors will implement these technologies on different schedules and in different ways. Using a vendor-neutral management solution gives you the ability to evaluate new offerings as they come out — and to select the ones that best meet your needs, even if they’re from someone other than your primary vendor.
• Mergers & acquisitions — in the U.S. alone, there were more than 11,000 mergers in 2006. Every time corporations merge, IT has to knit together the diverse infrastructure of the two entities. Smart IT organizations understand this and select vendor-neutral management tools that enable them to control the infrastructure they have today — and what they’re going to inherit tomorrow.
• Maintain flexibility and control your own destiny. If you rely on proprietary management solution, you don’t control your network — your vendor does. If your vendor end-of-lifes management support for your product, you’re stuck. Time to upgrade. When you’re negotiating the price of your hardware, you’re not going to get much of a discount if your provider knows that your management solution won’t allow you to switch to a competitive product. If you’ve got flexibility, you’ve got leverage.

With many IT departments embracing virtualization, AirWave fields an increasing number of questions from clients wanting to know if they can run the AirWave Management Platform (AMP) as a virtual machine on VMware or on another virtual platform. The simple answer to the question is a resounding, “Yes! — AMP runs just fine as a virtual machine.” As AirWave’s resident expect on server virtualization, I thought I’d take a few moments on a lazy Sunday to share with the AMP community what I call my Seven Simple Rules for running AMP as a virtual machine. Here they are:

Rule #1 - Choose Your Virtual Platform Carefully.

A few years ago virtualization choices were limited, with VMware dominating the scene. Today, the number of virtual software platforms has exploded, with VMware still leading the pack of closed-source and open-source virtual machines. But AMP is both a memory-intensive application as well as a CPU-hungry program — this tends to place hard bounds on which virtual platforms are well-suited to running AMP as a virtual machine.

If you were thinking of running AMP on any of the free offerings from VMware, think again; while AMP will run on these platforms, it won’t run well. In the lab, we’ve tested AMP on a VMware Server, and ran into several post-install problems, including scaling limitations, memory constraints and an annoying clock-drift problem when running as a guest OS on Windows operating systems. For best results, you definitely need a VM that will allow you to virtualize AMP with a minimum of 2 GB of RAM and preferably at least two virtual CPUs. VMware’s ESX offers these options, as do a few other virtual machine platforms.

Rule #2 - Remember the Hardware Requirements

One of the oft-touted advantages of virtualization is that virtualization gets you off the hardware hook; with a virtualized application, hardware isn’t supposed to make a difference, and both operating systems and applications can gain true independence from hardware. However, what’s true for device drivers and system architectures isn’t always true for scalability. As noted above, AMP will not run well on your average $200 PC-of-the-Week special. If you want to run AMP as a virtual machine, you need to keep the hardware requirements firmly in mind.

Virtualization enacts slight a tax for hardware independence — typically, 256 MB of RAM, 10% of the CPU and a few gigabytes on the hard disk. That may not sound like much, but it means that you’ll need a beefy box to run AMP in a virtualized environment. We recommend you virtualize AMP on dedicated hardware, and that you leave some room for expansion. Think about systems with at least 4 GB of RAM and preferably a quad-core processor. AMP’s published hardware requirements are your best bet for properly scaling the system you’ll use to virtualize AMP.

Rule #3 - You’re Entering the Red Hat Zone

The AMP install ISO is based on a derivative of Red Hat known as CentOS. The advantage of CentOS is that it’s free to redistribute and it costs nothing to upgrade as bug fixes and new Linux packages become available. The current version of the AMP ISO (as of AMP 5.2.3) runs CentOS 4.3, which maps directly to Red Hat 4.3. The next scheduled release, AMP 5.3, will run CentOS 5.0, which maps to Red Hat 5.

Whenever you’re presented with OS options by the virtual machine, usually during install, choose the option for Red Hat 4, or Red Hat 5 if you’re using an AMP ISO based on the CentOS 5 system. The same applies to installing VMware Tools (more on this later).

Rule #4 - Use Expanding Disks

Most VM implementations allow you to choose to use an expanding disk, or allocate the entire disk space during install. Unless you have a SAN-based virtual infrastructure, or have a complex disk partitioning scheme in mind, expanding disks offer far more flexibility at very little cost in performance.

The first beauty of expanding virtual disks is that they start out small, making it much easier to port them from machine to machine via LAN, WAN or even old-style SneakerNet with an external drive. The second beauty of expanding disks is that they allow you to create large partitions for future growth without having to immediately allocate the byte space on a real disk. The performance penalty, on the other hand, doesn’t seem to be much at all. However, not setting up a large enough partition for AMP at the beginning can be a real show-stopper — there are ways to bump-up partition sizes post-install, but none of them are what I’d call easy. Save yourself the hassle and start with a partition size large enough to accommodate both current and future needs, and let the VM expand the disk file as needed.

Rule #5 — Beware the Virtual Console

All virtual machine implementations offer an interface to the console of the guest OS, essentially a window displaying what you would see on the screen if you could actually attach a screen to a running virtual OS. In the case of AMP, virtual console displays are unnecessary, and can slow down your work with a virtualized version of AMP.

Most virtual console displays assume that you’re running a guest OS offering a graphical interface at the system console, which is not the case with AMP. Technically speaking, AMP’s console runs in a Linux/UNIX mode known as INIT 3, which is a purely text-based console mode. VMware’s remote console application, to use as an example, creates a screen scrape of the guest OS virtual console and then throws those bits across the network for reassembly on your console viewer application. This works great for a GUI-based console, but it’s inefficient and needlessly slow for a text-based console. Consider, instead, using SSH for access to the AMP command line. It’s faster, it uses far fewer network resources and in the limited number of cases where you need to access AMP at the command line instead of via the web-based GUI, SSH is a much better method of doing so. PuTTY is a great Windows SSH application, and you’ll find it faster and easier to use than a virtual console.

Rule #6 - Installing VMware Tools in a Text-based Environment

I always recommend installing VMware Tools (or other like-minded virtual machine post-install packages) on virtualized AMPs. Unfortunately, VMware’s instructions for doing so in a non-GUI environment are incomplete as they assume a desktop, etc. Have no worries though; it is possible to install VMware Tools on a virtual AMP. It’s also surprisingly easy, if you know the method.

First, while AMP is running use the VMware console to start the VMware Tools install. Next mount the VMware tools ISO at the AMP’s command line:

mount /dev/cdrom /media/cdrom

Again from the command line, extract the VMware Tools TAR file to AMP’s /tmp directory:

cd /tmp/; tar -xvzf /media/cdrom/VMwareTools-7.6.2-62573.tar.gz

(Note that the exact name of the VMware Tools TAR file will very likely be different from the one in the example above; use the full filename of the gz file you’ll find in /media/cdrom)

Finally, run the VMware Tools install script and choose all of the default options during install:

/tmp/vmware-tools-distrib/vmware-install.pl

Rule #7 - Learn to Love Disk Image Files

One of the things I like best about virtualization is how easy it is to quickly install an operating system using just a disk image (ISO). I always surprise my colleagues at AirWave with how quickly I can install a test AMP using nothing more than a disk image and a free virtual machine.

Depending on how much disk space you have available, consider keeping around an AMP ISO and a copy of your virtual machine disk. There are some interesting tricks you can do with a virtual AMP that are difficult or impossible to pull-off with your typical system-based installs. Considering an upgrade to a new version of AMP? Test it on the AMP virtual disk copy first by building a new virtual machine around it, without ever having to shutdown your production AMP. Or, as an alternative, build a fresh AMP install with the ISO, then load an AMP backup to check the upgrade. Want to know if a memory upgrade will improve AMP’s performance? This is easy to test with a virtual machine. With AMP and a virtual disk image file, the sky’s the limit to what you can do.

Lately, I’ve had a lot of people using the Airwave Management Platform (AMP) ask about how to integrate AMP with existing customer portals.

Luckily, the AMP server contains an XML API that allows customers to access all sorts of information that they are used to seeing in the AMP GUI. All of these API’s are documented on the Home -> Documentation page.

One use case for using the XML API is to look up clients by MAC address on the wireless network using a third party application. The API call looks like this:
https://xxx.xxx.xxx.xxx/client_search.xml?query=4b:5c

In this case, we want to know about all users that have ‘4b:5c’ in their MAC address. The output includes (among other items), the full MAC address of the client, username, DNS name of the device, and VLAN id. This data can be used for all sorts of purposes in custom portals and external applications.

Another way to access data is to ‘scrape’ screens directly from the Airwave GUI. For those of you who have AMP installed today, you’ve probably noticed that in the URL, there are a lot of pages that end with ‘?id=xxxx’. An example of this would be the AP Monitoring page. Normally, the URL for that page looks like the following:
https://xxx.xxx.xxx.xxx/ap_monitoring?id=12810.

This URL will get the AP page with all the navigation tools bar and AMP status information at the top of the page. But, what if you just want the AP information to insert into another portal page? By inserting a ‘/nf/’ into the URL, we can access just the AP monitoring data. Using the same URL example above, we end up with this URL:
https://xxx.xxx.xxx.xxx/nf/ap_monitoring?id=12810.

These are only two simple examples, but the reality is that with just a little bit of creativity, you can really unleash the power of AMP in to your custom applications.