In case you missed it, we hosted our 2nd-highest attended webcast ever on Tuesday, “Troubleshooting the Wireless LAN.”

Beyond the large attendance, the demand for a recording of the webcast post-event has been overwhelming!

So, without further ado, we present to you our newest addition to AirWaves:

Click to view “Troubleshooting the Wireless LAN” Webcast

If you have any questions or comments regarding the show, please direct them to the forum!

Here are a couple of slides that we went over, giving you an idea of the show:

Enjoy!

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.

Managed Service Providers (or MSP’s) have been participating in a pretty high growth business environment over the last few years. These organizations range from the major Telcos (Verizon and AT&T) to major hardware vendors (IBM and HP) to major System Integrators (CSC and Accenture) to regional niche players. It seems that just about anyone who is involved in IT wants to join the lucrative business of outsourcing or co-sourcing their customers networks and environments.

As WLANs become more prevalent and mission critical, this new area of networking is drawing the attention of many of these players. A year and a half ago, Verizon Business was one of the first to jump in a public way into this arena. It makes sense with Verizon’s history of wireless, networking, and now outsourcing, that they would be a leader in WLAN management. But Verizon Business is not alone in this field. Just about every MSP that offers network management is preparing to also offer WLAN management.

As these organizations enter into the WLAN management arena there are a few pitfalls they need to be aware of:

1. WLANs need to be managed differently the LANs. Due to the inherent nature of wireless, these devices need to be monitored in very different ways than their router and switch brethren. MSPs who make the mistake of just offering simple “up/down” status will not be doing their customer any favors - it is critical to provide RF management and optimization to ensure that not only are devices up, but that the network is actually working.
2. WLAN management needs to be integrated with LAN management. I think MSPs grasp this one pretty quickly - from a purely cost perspective. If the MSP has to build out a parallel infrastructure just for WLAN management then it will take them a long time to make a profit. By integrating WLAN specific tools into their existing operational infrastructure they can gain leverage and re-use many of the skill sets and processes that they have in house.
3. WLAN is just the beginning. Any MSP who starts discussing with their customer about managing their WLAN needs to understand that its not just the APs and/or controllers that need to be managed…it’s all the rest of the network as well. This includes the authentication infrastructure, the wired network that the wireless devices connect to, power, firewalls, etc. This is a great opportunity for the MSP to showcase all of their wares but they have to have this mindset from the beginning.

MSPs have a great opportunity in the WLAN space and can provide a fantastic service to their clients. As this market matures this level of service is going to become more and more important.

Many people assume that WiFi mesh networking is a technology only for the municipal wireless market, and not for the enterprise. In reality, we see many corporations and enterprises using mesh technology to deliver wireless connectivity in certain types of environments. Few enterprises are using mesh devices to provide coverage in carpeted office areas where it’s not too difficult to provide an ethernet connection. But many are using mesh where it’s more challenging and costly to deliver ethernet: in large warehouses or manufacturing floors, in mines, in large airport terminals, etc. In these areas, the cost of delivering an ethernet connection can be many times the price of a wireless access point.

Where this is the case, mesh technology’s ability to extend the reach of wireless without costly cable drop offers significant cost savings and a very attractive value proposition. Over the past several years, we’ve seen IT organizations become much more sophisticated in the design of their wireless networks. Rather than trying to find a single ‘one-size-fits-all’ technology, they’re selecting the best technology for each operating environment and to support the applications that will be used in that area.

At AirWave, we often talk about how wireless networks inherently become more heterogeneous as they mature and expand. The selective, intelligent use of different wireless technologies is just one more example of this heterogeneity.

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.

Recently some of my colleagues attended the National Retail Federation show in New York City. Just before show started, AirDefense did a survey of almost 800 stores in the New York City area to get a sense of what kind of security was in place. The results, while very dismal for retailers, are not very surprising at all. There were still many places where no security is in place or the easily broken WEP key was still being used.

This brings us to a bit of a quandary. How do we make it easier to implement better security and provide a way to audit the network while detecting rogue devices? Well there are a couple of things that we can do to help mitigate the security risk.

First, there needs to be a realization that security is not just a ‘point’ product or a ‘once in awhile’ process. It’s something that needs to be integrated directly into the organization. Using tools that can manage configurations centrally and can audit the network to make sure those configuration policies are consistent is key. This applies to not only the RF settings (i.e. what you’re broadcasting out of your AP), but also the wireline side of your devices. Remember, there are threats coming from inside the network as well!

I’ve been into many customer sites over the years, many of them retailers, and it still amazes me how some customers can be so organized where they know each and every configuration setting on their devices, while others haven’t the slightest clue what’s actually running in their own network. How can we have a secure network that will pass PCI audits when no one actually knows what’s loose on the network?!

The second item that the survey brought up was the number of potential rogue devices that were deployed. PCI today only requires quarterly scans for rogue devices. I’m not sure about you, but that seems a bit long to me! Putting in automated tools to detect these devices as soon as possible is much more in the spirit of true security. In addition to doing wireless scans, which only determines that someone is bleeding into your RF space, performing a wireline scan to determine if the device is truly a security threat is important. By determining whether a device is actually plugged into the wired network it reduces the amount of work involved with determining whether something is ‘truly’ a rogue or if it’s just the AP in the Starbucks across the street.

The whole key to this endeavor is to take the concept of security and making it a part of the day to day operations of the IT staff.