I was listening to a presentation on the evolution of the WLAN architecture. Most of these presentations begin with the advent of the “fat” AP (autonomous) and then transition to the newer “thin” (controller based architectures). Some are now talking of a 3rd generation which speaks to a hybrid AP architecture where the AP can be “fit”. By far the biggest change between the 1st and 2nd generation is the use of a controller (or wireless switch). This was initially pitched by the likes of Airespace, Aruba and Trapeze as the “end all, be all” way to centrally manage a wireless LAN. What I find very interesting is that the 1st generation WLAN deployed at the enterprise actually used a controller. Yes, it got very little press, but nonetheless they did use a controller.

Let me explain. When most corporations began deploying WiFi back in 2002 the only real security option they had built into the access points was WEP based encryption. WEP was easily hacked and made all kinds of press early on. Plus WEP took care (sort of) over the air encryption but didn’t really protect an enterprise from unauthorized users. So enterprises began using their existing infrastructure to secure the WLAN - those existing VPN servers. What they did was they created VLANs for the wireless APs that were basically unprotected - pretty much a DMZ. Wireless users could associate to the APs but the only place they could get to was the VPN server. A wireless user would then pull open their VPN client, authenticate and then they would be re-routed back to the corporate network. Enterprises treated wireless users as if they were remote. I thought that this was a great solution using existing infrastructure plus the enterprise got authentication and real encryption for their WLAN.

The major downside to all this is two-fold: first, the VPN infrastructure wasn’t robust enough and second, the packet flow was sub-optimal. Most corporations built out remote access via VPN to support maybe 5% of their user population. VPN concentrators can be pretty expensive and a bit difficult to support. Once wireless users began using this infrastructure usage patterns went through the roof. Corporations were finding themselves having to invest even more money in VPN servers as wireless users doubled and even tripled their previous pure remote access usage patterns. The network access path for wireless users was also kind of strange. You basically took a user sitting within the corporate walls, forced them outside of the corporate network, put them on the internet and then forced them back into the corporation and then to their local network. Not the most obvious and efficient flow.

So what did the industry learn from all this? First, an enterprise security solution had to have authentication and strong encryption (now we have 802.11i). Second, having a separate data plane (VLAN) for wireless was OK as long as it didn’t become too circuitous. The second generation WLAN vendors took this to heart and offered controllers that would be deployed on local subnets. They started out by offering layer 2 solutions but eventually moved to layer 3 as customer wanted to leverage their existing open switch ports.

Now we are left with 2 camps, those that offer some form of “unified” architecture and those that are “overlay” solutions. Unified solutions promise to integrate wired and wireless functionality - basically to add controller like functionality into existing switches and routers. Cisco and HP ProCurve are the leading vendors here. The overlay vendors say that wireless still needs to be kept separate and re-routed onto the LAN once users have been approved (Aruba). Sitting in the middle in a more hybrid architecture are companies like Trapeze (they OEM to Nortel, 3Com and Enterasys) that say that authentication and configuration information should be communicated back to a controller (overlay) but data traffic should be put directly on to the LAN. I can see this last approach showing a lot of merit as it leverage the second rule we learned from the VPN solutions.

I also see a lot of merit in the unified approach once these vendors truly integrate the WLAN controller functions into their switch and router software. Today all of these solutions take the form factor of a controller (most controllers today are just PCs) and shove it into a blade or card that goes into an existing wired switch or router. The only thing that is integrated is that these functions sit in the same box. Truly unified WLAN solutions will encompass a switch or router that does not care if you are wired or wireless, and if you are wireless they will have the intelligence to authenticate and encrypt your traffic while you traverse the network in a direct manner.

I was meeting with a potential client and we began discussing their business drivers for deploying wireless. We often ask this questions of companies and we normally get the typical responses:

1. Our (insert exec title here) has wireless at home so now we have to make it work in the office
2. Cisco gave our CIO a great sales pitch
3. We have some special applications that require mobile devices that can only connect via wireless (VOIP phones, bar code scanners, mobile printers, etc.)
4. Its for our conference rooms and other gathering places that are inconvenient to plug into

Well this company was quite a bit different and I think quite forward looking. Their belief is that wireless costs less, is easier to secure, and gives them more flexibility over wired network. Period. No caveats. Most IT people can buy part of the flexibility argument, but only in certain locations or specific type of work environments. No one in IT that I have ever spoken to would dare argue the security and cost element. Let me lay out their thought process.

First is cost. Today this company is in a growth phase and they are constantly adding new office space. To set up a new facility they have to go in, wire the building, put in physical security, furnish the office, assure there is power, etc. By far the biggest lag time they have is in wiring the place. If they can remove the need to roll out ethernet to every office and cubicle they assume they can decrease their new office roll-out time by over 50%. They obviously translates into serious cash.

The second argument is security. Like most large organizations they are trying to move to a NAC based architecture on the wired side of the network. 802.1x (port based authentication) makes a lot of sense and the added virus scanning/patch management/end point security elements of NAC in theory are great. But when you have tens of thousands of employees and thousands of switches and routers, the cost and complexity of NAC is overwhelming. But with wireless, 802.1x is basically built in. Flip on WPA2 on your access points (and/or controllers), integrate with that radius box and configure the existing supplicant on your microsoft laptop and off you go (well its not quite that easy but close). Wireless networks are indeed very secure today (when properly configured) and in this particular companies view a lot easier to roll out than retrofitting their existing network. Big security advantage…as well as even bigger cost savings.

The final issue was flexibility. This particular company is often having employees juggle their work space; moving from one cube to another, changing office, reconfiguring work spaces, etc. This seems to be a them in many corporate environments as organizations begin to tear down the cube walls in favor of “collaboration”. Well, being tied to a physical port puts a real damper on this and limits their movement to the distance their ethernet cable can reach. With wireless its move to your hearts content. Some wired bigots may say “but that ethernet port is so much faster than wireless, how can you abandon it?” Well with 802.11n that problem will be gone. So more flexibility at the same speed and bandwidth of that old stodgy ethernet port.

Pretty exciting stuff!

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.

Learn the latest developments in Fixed/Mobile and Mobile/Mobile Convergence — and what you need to know for managing convergence of voice and data on your wireless network and on single wireless devices– from leading wireless industry analyst Craig Mathias of the Farpoint Group – part of AirWave’s “Staying Ahead of the Curve” series of webcasts.

Click to view the “Fixed-Mobile & Mobile-Mobile Convergence” webcast

Interesting article in yesterday’s NY Times on how Netflix is using its live customer support to differentiate itself from competitors like Blockbuster. (As a Netflix customer, I can testify that they do a great job. No waiting on hold!)

It’s a smart move. One of the things that smaller, specialized companies typically do well (compared to their larger and more bureaucratic rivals) is to focus fanatically on customer support and on meeting their customer’s needs.

We’re a technology company supporting technical users in IT, so it’s particularly important that our customer support engineers be exactly that: engineers. If the customer on the other end of the phone knows more about the product than the support team, you’ve got a problem. It’s also critical that the customer support engineers have regular contact with the developers building the product — so they can get fast and accurate answers and can provide direct input to the developers on what’s working and what’s not [At AirWave this is easy — the customer support engineers have to walk right through the software development area when they arrive at work, when they leave, and whenever they want coffee].

For IT customers evaluating technology products, I’d recommend making testing customer support teams and processes a critical part (if not the most critical part) of the vendor selection process: call the support line, talk to the people, assess their knowledge, see how quickly they respond to your requests for assistance. You’re not just buying a product, you’re buying a team.

If you work at the user helpdesk in an IT organization, you know that most users only report two problems related to wireless: (a) “I can’t get connected” and (b) “The network is slow”. Your job is to figure out what’s really going on: Is it a network problem? An RF issue? Or did the @#*&% user change his client settings again? While you have the user on the phone (and before you get too far in your diagnostic process), make sure you know the answer to these basic questions:

1. Is the user actually connected to your wireless network? [Sometimes a user may have connected to a neighbor’s network without knowing it or he might be connected to your network but having difficulty authenticating]
2. Is the user authenticated?
3. Where is the user located? Should you have strong wireless coverage in that area?
4. Are all access points or controllers in the area operational?
5. Which access point is the user closest to?
6. Are other users connected to that AP? [If so, it’s much more likely that the network is fine but your user has a client configuration problem. If not, you might have a network problem.]
7. Is the user receiving a strong RF signal?
8. How does current wireless usage in that area compare to recent trends? [If network usage is a lot higher than usual, you may have a capacity problem]
9. Has the user successfully connected to your wireless LAN in the recent past? Using the same device?
10. Has the user tried enabling and re-enabling hiw wireless radio? Rebooting?