Review: Meru Networks’ E(z)RF Service Assurance Module
Meru Networks launched on the Nasdaq stock exchange this month – and eWEEK took a look at how its E(z)RF Service Assurance Module benchmarks an office Wi-Fi network
Creating Performance Baselines
To start, network administrators need to create two performance baselines with the SAM: the first to measure connectivity (latency in milliseconds plus packet loss in raw numbers) and the second to measure bandwidth performance (in Mbps). With baselines established, the administrator can schedule health checks to run periodically, with hourly, daily, weekly or continuous recurrence schedules available. Administrators can also schedule one-off or on-demand health checks.
One would think that the SAM would compare the results of each health check to the baseline, but that is only the case with one of the tests. A throughput health check measures its performance in relation to the baseline, providing evaluative ratings as defined by percentages set by the administrator. For instance, I defined the upper threshold at 50 percent and the lower at 25 percent, meaning any throughput measurement achieving 50 percent or greater of baseline will be rated by the SAM as “good,” anything below 25 percent “bad” and the rest “fair.”
On the other hand, the connectivity baselines are informational, but not used as a basis for ongoing comparison with health checks. In this case, the administrator must instead define the upper and lower levels of acceptable latency and packet loss throughout the network.
Determining when to run baseline tests is a bit of a philosophical argument. To measure ongoing performance against best-case scenarios, administrators should time baseline collection for times when wireless traffic and potential interferers are at a minimum. Or network administrators may want ongoing health checks to be compared to normal operating condition baselines, which would be collected during work hours.
Ideally, it would be great if health checks could be measured against both measurements taken under both circumstances, but the SAM doesn’t work that way. I could run a bunch of baselines at different times of day and keep them in the system, but only one of each type of baseline is active at any time. Health checks are compared only to the active baseline, and there is no way to automatically switch baselines behind the scenes.
I also found that the baseline measurement taken determines what specific networks and APs are tested during a health check. An ESSID (Extended SSID) or an AP that was not part of the baseline will not be part of health checks taken while the baseline is active. If I want to omit certain ESSIDs from future tests (for instance, if I don’t want to benchmark a guest network), I could clone a baseline within the SAM and edit the resulting baseline to omit certain ESSIDs, access points or radios from future health checks.
When a baseline is initiated, the SAM contacts the Meru wireless controller defined for the test, pulling down the controller’s saved configuration file to get a list of all available access points, as well as all the configured ESSIDs and their security settings. Then, the SAM pushes a virtual client to an AP, which in turn associates itself with another AP on the network. If the AP supports both the 2.4GHz and 5GHz bands, each radio will be tested in turn.
Once associated to the network, the SA appliance sends traffic over the wired network to the virtual client-hosting AP, which transmits the traffic over wireless to the other AP, which then routes the traffic back over the wired network to the SA appliance. For the connectivity tests, the SAM utilises a 10-second or so burst of ICMP traffic to measure network characteristics, while the throughput test uses a built-in iteration of the iPerf test tool to measure upload throughput.
Continued…
