Making Sense of Meru Decodes

Making Sense of Meru Decodes

By CWNP On 08/03/2011 - 33 Comments

Let’s face it: Meru does some creative stuff with the 802.11 protocol. By concentrating all users on the same channel, they give up some of the capacity of the available Wi-Fi frequencies. As a tradeoff, they gain some client control. Centering all WLAN operations on a single channel allows (or forces, depending on how you see it) them to do some interesting things with the protocol to make up for some of that sacrificed capacity.

For WLAN consultants and engineers that troubleshoot many different networks, they are often a bit confused when it comes to a Meru decode. Here are a few quick tips for understanding the trace.

Virtual Cell technology uses the same BSSID across all APs and all clients on the same channel. This is one type of virtualization that, in a decode, will look like a single AP across your enterprise. The single virtualized AP will broadcast beacons regularly, as with most networks.

Virtual Port technology uses a unique BSSID for each client. Yes, that’s right…for each client. So, if you have 10 APs with 10 clients each, you will see 100 beacon streams. In a decode, this will look like 100 different APs. To make sense of all those Beacons, you have to understand how Virtual Port works.

First, the APs do not beacon like other vendors. In most WLANs (from Cisco, Aruba, HP, etc.), when you configure and enable an SSID, each AP begins beaconing for that service set. Not so with virtual port. In virtual port, since beacon streams are per-client, no Beacons are sent initially (i.e. no global beacon for the service set). Instead, the Meru infrastructure waits for each client to show interest, then begins beaconing for each client dynamically, starting and stopping beacon streams as the client comes and goes. The infrastructure starts beaconing for a client when it receives a probe request. This is interesting to watch in a live capture, especially if you are able to fire up the Meru APs in a clean environment. Your sniffer can monitor a clean channel with no activity, then suddenly a client probes, the APs respond, and a Beacon stream is born.

Troubleshooting the basic connectivity process with Meru can be complex because client discovery behavior varies for each client. Some clients do not send probe requests. Thus, if they don’t send probes, no Beacon stream is present. If clients rely on passive scanning only (or use active scanning selectively), they may not discover the network.

When troubleshooting clients with active Beacon streams, you may be wondering how to know which Beacon stream is for which client. Each Beacon stream can be matched with the client by looking at the two halves of the BSSID and comparing it with the MAC of the client. Specifically, the first half of the BSSID uses Meru’s OUI. The second half of the BSSID mirrors the second half of the client’s MAC address.

For example, if my Intel client is 00:21:5C:50:16:B1, the Meru Beacon will use MeruOUI:50:16:B1. See the graphic below that shows a beacon ending in 50:16:B1 then a data exchange in which the receiver, transmitter, and BSSID all end in 50:16:B1. This is interesting!

For other vendors, each AP uses a single BSSID for each SSID. The BSSID is some iteration of the radio’s base MAC address, which makes it easy enough to correlate a BSSID with the physical AP. In a Meru network with these different virtualization techniques, how would you know what AP the client is associated to? How do you know how many physical APs there are in your environment?

The answer is to rely on a Meru vendor-specific information element (IE) in Beacons. The picture below shows a Meru Beacon, captured by AirMagnet. Thanks to AirMagnet for interpreting this Meru information element for us. That is a big help. If you have to do it manually, you’ll just have to remember the octets that contain the important information.

There are two primary pieces of information that will help us here. The first one is an AP ID. This is the ID assigned to an AP by the controller. As you can see below, this AP had an ID of 7 (the 8th octet of the Meru IE). The second piece of helpful information is the AP’s serial MAC address (not to be confused with the base radio MAC address). The 14th octet of the Meru IE is the first octet of the MAC address. As troubleshooting goes, you’ll be able to use this MAC address to identify the specific AP to which the client is associated. If you have access to the controller, a simple show AP <ap-id> (e.g. show AP 7) will tell you more about the AP, including its serial MAC. When troubleshooting Meru networks, you might consider laying out a floor plan image and charting APs by their serial MAC.

It’s all a bit interesting and a bit confusing at the same time. If you never see Meru in the field, consider this a lesson that every vendor uses the spec as a general guideline and not an absolute rulebook. If you do see Meru in the field, I hope these tips will prevent some head scratching.

A Rant: Misleading Marketing?
Meru advertises their WLAN virtualization technologies as “a wireless LAN equivalent to switched Ethernet in every way except that users are no longer tied down by wires…” I fully understand that Meru’s Virtual Port technology uses some advanced algorithms to coordinate AP transmissions; Virtual Port also provides some enhanced per-client control of wireless contention (that’s great). However, the client control is not absolute and—more importantly—virtual port does nothing to segment RF collision domains nor add bandwidth. Contrarily, by putting all clients on the same channel (same collision domain), Meru almost becomes less switch-like and more hub-like.

Many network professionals are already confused about how wireless contention differs from switched networks. Bad marketing doesn't help the problem. Equating any wireless network to switched Ethernet is just silliness, and in my opinion, flirting with deception.

Final Comments and Suggestions (FCS)
I prefer not to end on such a negative note, so let me conclude with an education suggestion: Know the protocol AND the vendor-specific behavior. Our recommended approach to WLAN education is to start with vendor-neutral training (i.e. CWNP) to learn the technology and protocols. But, we are also big supporters of vendor-specific training (yes, you read that right). Just like every other vendor, Meru has plenty of proprietary WLAN functionality that engineers should know about.  Marrying the vendor-agnostic and vendor-specific will help you understand and evaluate all of the protocols—as well as the confusing marketing. :)

Blog Disclaimer: The opinions expressed within these blog posts are solely the author’s and do not reflect the opinions and beliefs of the Certitrek, CWNP or its affiliates.