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.

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.

 

 AirWave Podcast with CSU San Marcos [15:31m]: Play Now | Play in Popup | Download

As some of you may have heard, the California State University System announced back in September that all 23 schools will eventually be moving off of Cisco WLAN gear and onto Aruba Networks products. AirWave is currently being used to manage and monitor wireless networks at 7 of the CSU campuses including CSU San Marcos.

In this episode of AirWaves I spoke with John Humes who is the Network Manager at CSU San Marcos and was on the evaluation committee that selected Aruba as the standard for the CSU system moving forward.

Like many of the CSU schools, San Marco is currently using Cisco for their WLAN infrastructure and John discusses the issues he faces on a daily basis and how a tool like AirWave makes his life easier.

John also describes the migration path and how AirWave’s multi-vendor capabilities will play a strategic role in their network moving forward.

Last week I spent some time doing half-day AirWave training road shows. Most of the folks in my classes were from small to medium size companies and the types of questions that I received really hit home that there is still a lot of wireless training that needs to be done to bring everyone up to speed.

For example:

• Why in the U.S. do we typically only use channels 1,6, and 11?
• Should all of my APs at a single site have the same SSID’s?
• What does RSSI and dbm mean when talking about wireless signals?

These are basic questions that all wireless administrators should understand.

There are several courses out in the market place today that try to address the basics of wireless networking. I would recommend some of the CWNP classes (www.cwnp.com). These courses are great for people who already understand some of the basic network concepts, but want to elevate their wireless knowledge level and increase their marketability to employers.

This morning, we announced that AirWave has agreed to merge with Aruba Networks. We expect this to be great news for our customers. Our mission remains absolutely unchanged: to develop the premier multi-vendor management software that allows our customers to operate and support their wireless networks.

Aruba is fully committed to operating AirWave as a business unit focused on developing and providing multi-vendor management software. The AirWave software will simply get better, because we’re going to have the resources of a larger organization behind us – and we expect this will enable us to add support for even more hardware vendors. Supporting the leading hardware vendors that our customers choose is critical to everything we do.

We believe in open, standards-based technology – and in giving every customer the freedom to choose the products that best meet their specific requirements. Aruba believes exactly the same thing… and that’s why this combination makes so much sense to us.

I’ve spoken with and emailed a number of AirWave customers this morning and have been very touched that many so people’s first questions have been, “What does this mean for AirWave employees? Is everyone going to be OK?”. First… I want to thank everyone for their concern for the people they’ve built relationships with over the past several years. I also want to reassure everyone that this transaction is a very good thing for the people of AirWave – AirWave’s employees are being kept together as a team and will operate as business unit. This will provide us the additional resources we need to develop even more interesting applications in the future.

From a customer perspective, nothing changes. You should call the same support number, talk to the same people, log into the same user forum… We’re here to help, and if you have any questions, just give us a call.

Recently, while doing some wireless training, I’ve had a lot of questions about the importance of keeping historical data and how to use that for troubleshooting. When we get right down to it, troubleshooting any system that is already in production is all about the ‘delta’.

In math, a delta is the difference between two items. When troubleshooting network issues, the delta is the difference between when the network was working properly and when it’s not. In most organizations, it’s the networks fault until proven otherwise!

So, what are the items that we need to track effectively to determine what is different, when things aren’t going the way we expect? Well, it varies on the hardware and the type of network you have deployed, but some of the basic items revolve around user counts, bandwidth, client signal strength, and 802.11 radio counters. For effective troubleshooting using these values, we need more than just a day or even a week of data. In some cases, we need months or even a years worth of data to identify trends.

Let me give you some real world examples where these values are important. First, we have user counts and bandwidth. These two values tell us about the utilization of the network. Most AP vendors will have a recommended maximum number of users per AP. When looking at this trending data, are we passing this number when users start complaining? Bandwidth is a little easier to trend since we know we only have so much bandwidth available, depending on the radio mode we’re using.

Client signal strength and 802.11 counters are a bit more ambiguous. These are the values that without historical information have almost no context. Often the ‘slow’ network issue from users is really a lack of good wireless signal. This can be caused by the user being in an area where there is a known lack of coverage, or it can be because something changed in the environment that is causing an issue. I’ve seen things like new construction (unknown to the IT staff of course) or, my favorite is the twenty pallets of canned beans that get delivered to the warehouse that drastically change the RF coverage.

Looking at the 802.11 radio counters can be an eye opening experience. These values usually relate to reception (i.e. interference issues) and transmissions errors. Things like transmission errors can be caused by stolen antennas (mostly in high schools!) or if you’re using outside antennas and the errors peak when it’s raining, you are getting water down into the coax. Reception errors are more varied, but generally point to some sort of interference. This can be caused by things like microwaves (the graphs will jump up during the lunch hour) or cordless phones. I had one situation where all the clients at a facility dropped off the wireless network every Tuesday at 1pm. I verified the wireless disconnect by looking at the roaming history for the clients. When I looked at the 802.11 counters, I saw a spike in the receptions errors every week at the same time over the last couple of months. After further investigation, it turned out to be the backup generator on the roof doing its weekly self test!

So, the rule of thumb when troubleshooting an already deployed system is to find out what the network looked like when it was working properly and what’s different now, when the network is misbehaving.

 

 AirWave & Intel Podcast [20:18m]: Play Now | Play in Popup | Download

I had the pleasure to record a podcast with Ray Sliteris of Intel to discuss how they manage their internal wireless LAN on a global basis. Managing over 6,000 access points and controllers is a pretty huge task for any corporation; these guys have the added benefit of working for a company that is a main driver behind the entire WiFi industry.

A few interesting items that particularly caught my attention:

1. Last year they were almost 100% autonomous access points and now they are about 25% converted to a controller based approach. This migration will take them several years to move entirely to a thin AP model. My guess is most organizations are like this, they would very much like to take advantage of the “latest and greatest” but due to organizational inertia and network size it takes a while to make any radical changes.

2. The biggest challenges they faced in deploying a network of this size were creating consistent configurations and having a global network view.

3. 802.11n is not a big push for them. They are testing this new technology out in a few areas but they see this as a 2009 production deployment type of technology. The big business drivier for Intel will not necessarily be the additional throughput but rather the improved connection reliability inherent with MIMO.

Please take a listen to the podcast and let me know what you think!

After spending time with hundreds of customers over the last couple of years, I’ve noticed a lot of issues regarding SNMP configuration and login credential on access points and controllers.

It’s surprising how many companies are still using ‘public’ and ‘private’ as their production strings!  Since these strings are passed as clear text on the network, not only should they be set to something other than the default strings, but they should be changed on a regular basis as well.  Another tactic that I’ve seen customers use is to have different strings for different devices or to have unique strings for devices in different locations.  For more security, use SNMPv3 on all the devices in your network that support v3.

SNMP v1 and v2 are really not much more secure than the way some kings in the Middle Ages sent their secret messages. They would write the message on the bald head of the messenger, let the messengers’ hair grow out, and then send them to the other King.  This is security by obscurity – it’s better than nothing but is not very effective once someone figures out to shave the heads of all the messengers! If you’re sending your SNMP v1 and v2 settings in the clear, a moderately clever intruder might be able to figure out how to get on your network.  Most enterprise-grade WLAN hardware supports SNMPv3 today… make sure your vendor provides it.

Besides, SNMP issues, I see a lot of customers still using the default credentials for login access.  Not changing the factory default credentials on your network devices is like sending out the messenger without even letting his hair grow out!  The best security in this case is to NEVER use the factory IDs and use a centralized user ID and password source.  Also, while you are at it, make sure you disable telnet and HTTP!  There is no sense in setting a secure authentication scheme to just send it out over the network in the clear.

I was at a presentation yesterday hosted by Getronics on the merits of their wireless security and implementation methodology code named WISDOM. The basic gist of WISDOM is to use existing management process frameworks like x.805 and ITIL and marry them with the latest and greatest wireless and security technology (editors note: this is a huge simplification). This breaks down into looking at the network in a three dimensional landscape. On one axis you have the 3 security planes: management plane (configuration), control plane (QoS, VOIP, etc.) and end user plane. On another axis you have the 3 security layers: Application, Services (FTP, HTTP, etc.), and Infrastructure. You then have the third axis which are the 8 security dimensions: access control, authentication, non-repudiation, data confidentiality, communication security, data integrity, availability, and privacy. Getronics raps around the three legs of their practice around this model: security, process & procedure and technology.

What really stuck me about this is most WLAN technology vendors build in the security and technology aspects into their products but they almost always forget the process & procedure. Let me give you an example. Almost all LAN hardware vendors build some sort of “management” into their products or offer some software tools. Most times these tools help an engineer configure the device, change and update firmware, troubleshoot packet level problems, etc. But almost never do these tools take in mind the process & procedures an enterprise needs to go through to allow these things to take place in the first place.

For a long time I have wrestled with how to market certain features in our software that revolve around how an IT organization works with the tools they are given. We have experimented with terming our product an “Operations Management” platform versus an element manager. We tried to capture the fact that we only show data about the network to those people who are authorized to see it. As an example, someone from the help desk who logs into our product can not see configuration data versus when the admin signs in they can see and edit configuration data. We even went a step further and began to segment access so that we can allow an admin from one department to log in and see/edit data in his department only versus the entire network. We also do things like integrate with syslog, send traps to other NMS systems, have an XML interface, and log all activity within the system. The features have almost nothing to do with WLAN management but are absolutely critical for an enterprise because they support their policies & procedures.

A reporter recently asked for a simple ‘quick tip’ that network administrators can implement today to make supporting a wireless network easier for the Helpdesk team.

Here’s one: Create a clear, consistent naming convention for your wireless access points and controllers so both your Helpdesk staff and network engineers can quickly search for and locate devices on your network.

Using solutions like AirWave’s software, it’s usually pretty easy to locate a user who is actually associated to the network by searching via username or MAC address. But if a user is NOT able to associate to the wireless network, the Helpdesk needs to be able to locate and monitor nearby access points quickly to assess conditions in the area… If the Helpdesk staff member can search by a logical, predictable AP name, they’ll save themselves a lot of time and be able to diagnose problems more quickly.

For example, a “Campus-Building-Floor-ID” convention might result in a name of “sanmateo-bldg214-flr5-NE” for an access point in the northeast corner of the 5^th floor of Building 214 on the San Mateo, CA campus. The exact convention you choose doesn’t matter as much as selecting a convention that humans can decipher and learn.