Wireless LAN Tools: Monitoring and Reporting (Part 4) - Page 2

By Lisa Phifer

August 17, 2004

Performance monitoring

Many of the capabilities discussed for security alerts also apply to performance alerts. Depending on the product, WLAN analyzers may detect conditions that reflect performance degradation, such as:

  • Co-channel interference between APs operating on the same or adjacent channels;
  • Associations at low data rates between devices that support higher data rates;
  • Devices transmitting 802.11 on channels not used in this regulatory domain;
  • Stations that roam too frequently, retry too often, or experience high error rates;
  • Concurrent use of Point and Distributed Coordination Functions (PCF and DCF);
  • High-speed transmission techniques that can interfere with other 802.11 devices; and
  • Behavior known to cause 802.11b interference, like 802.11g APs not using protection mode or long time slots.

As for security alerts, performance alerts may or may not represent an actual problem in your WLAN, and some tuning of the built-in performance alert list is usually required. Some performance alerts are a matter of local policy--if you're using Turbo mode or PCF intentionally, then you'd want to disable those alerts. But many performance alerts are based on thresholds. Getting the most from your analyzer requires tuning those thresholds to reflect "typical" behavior in your WLAN environment.

Click to view larger imageTo do so, use your analyzer's real-time monitoring features to eyeball performance characteristics of your WLAN. Watch traffic for a given channel, SSID, or AP to get a sense of signal, noise, utilization, speed, throughput, management overhead, and CRC error rates. For example, in this AirMagnet channel view, we can easily spot one AP with atypical variation in signal strength.

Click to view larger imageGraphing traffic characteristics can be helpful to see minimums, maximums, and averages over time, as well as repeating patterns. For example, this WildPackets AiroPeek NX graph plots data rate changes. The graph's sample interval can be adjusted to look beyond minor short term variations, or to examine a period where unusual highs or lows occurred.

Click to view larger imageUse real-time performance monitors, post-capture traffic analysis, and performance alerts generated at default thresholds to establish baseline performance metrics for your network. Then adjust your analyzer's thresholds to strike a balance between ignoring potential problems and being inundated with alerts that don't require action. For example, this Network General Sniffer Wireless panel can be used to tune default alarm thresholds associated with throughput, utilization, CRC errors, retries, etc.


Problem analysis

Of course, some performance alerts will require further investigation and remedial action. Traffic capture and analysis clearly plays a big role in fine-tuning to reduce errors and optimize network throughput and utilization. Many of the capabilities already discussed under troubleshooting (Part 3) and security (above) apply here as well. In addition, some WLAN analyzers offer advanced tools focused on performance measurement and tuning. For example:

  1. Click to view entire screen shotExpert analysis modules can examine traffic between hosts or during individual sessions to highlight symptoms of poor performance and isolate their cause. For example, this AiroPeek NX panel gives a detailed breakdown of performance problems associated with a specific host, and with a specific Web session established by that host. This user experienced poor Web response, but the real culprit here seems to be wireless retries and data rate changes.
  2. Click to view larger imageOnce you've spotted a problem, active measurement tools are helpful. For example, you might use AirMagnet Handheld with the tools shown here to better understand a station's experience. Visiting that station's location, use the Performance tool to measure throughput and speed to the AP used by the problem station; use the Coverage tool to measure SNR for the SSID used by that station. Ideally, these measurements would be taken using the same NIC as the problem station. When that's not possible, calibrating the analyzer's NIC to mimic the station's NIC can help.
  3. Click to view larger imageKnowing what's wrong doesn't necessarily mean you'll know how to fix it. Resolution through trial and error is common, but can be time-consuming and impractical in a production network. To estimate the consequences of a proposed change before implementing it, use a "what if" analysis utility like the one shown here from Network Instruments Observer. Note that this example estimates end-to-end application performance. A utility like this can predict what would happen if there were fewer clients or more bandwidth or shorter packets, but it can't tell you exactly which knob to turn to produce that result.
  4. Testing proposed fixes in a production WLAN can be challenging, because always-changing traffic can make it hard to repeat a specific problem scenario. On the other hand, analyzing performance in a test WLAN can be difficult due to the absence of traffic. Many wireless NIC clients include a test utility to generate traffic, and so do some WLAN analyzers. But coordinating independent tools running on many stations for load or stress testing is impractical. To generate high-volume traffic for performance optimization or capacity planning, consider using an 802.11 emulator like CMC's EmulationEngine XT.

Usage reporting and trend analysis

WLAN analyzers can help you keep tabs on network activity over longer periods of time by crunching monitored traffic to track and store traffic statistics. Long-term traffic observation, analysis, and reporting capabilities vary quite a bit, ranging from basic periodic reports to history databases that support extensive built-in reports and ad hoc queries. Here are just a few examples:

  • Click to view larger imageThis TamoSoft CommView panel can be used to generate a periodic traffic report in CSV or HTML format. An example Web report is shown here. Report options control how frequently that report is written during packet capture, and the traffic counts to be included in each scheduled report, such as byte/packet rates for each WLAN channel, protocol, and sender MAC or IP address. Periodic reports like this can be handy for look-back viewing and as input to spreadsheets and other traffic analysis tools.
  • Click to view larger imageThis Network General Sniffer Wireless panel can be used to create History Samples. Each configured Sample tracks a single defined metric, like bandwidth utilization, error rates, or the number of Probe, Authentication, Association, Deauthentication, or Disassociation requests per second. Samples continue to be recorded as long as the analyzer is running. Graphed or tabular results can be viewed/printed from the Sniffer console at any time, or exported for further analysis.
  • Click to view larger imageNetwork Instruments Observer Suite includes a Web server that enables traffic history database browsing by authorized administrators from any location. After logging into this server with a username and password, administrators can use a variety of built-in reports to view and analyze historical data in different ways, over different time periods, to spot growth in utilization or errors before they turn into problems. Data collection can run continuously on the Observer server, but you'll want to choose a sampling interval that strikes a good balance between storage requirements and report detail.

Click to view larger imageIf historical data is recorded with sufficient granularity, raw counters can be sliced and diced in many different ways to better understand network, device, application, and user behavior. For example, this Sniffer Wireless report provides an analysis of server response time, broken down by application type (Web, ftp, pop, smtp, etc.).


Click to view entire screen shotThis pair of Observer Network Trend viewers show how the same underlying history data can be used to generate statistics pertaining to individual APs, IP hosts, or even TCP sessions. Here again, you'll probably want to look beyond WLAN traffic, examining end-to-end traffic for an overall perspective on how your network is being utilized.


Conclusion

In this series, we have covered quite a bit of ground--and yet, we barely scratched the surface of the many WLAN analyzers illustrated here. Protocol analyzers are a bit like the proverbial Swiss Army Knife. You'll probably spend most of your time using just a few indispensable, well-worn tools. But as you explore further, you'll find that your WLAN analyzer includes many additional tools, the true purpose of which may not be apparent until you read the instruction manual or try to use them. So spend a little quality time digging into your favorite WLAN analyzer--the next time something mysterious happens to your WLAN, you'll be better prepared to spot and decipher the clues.

Reprinted from ISP Planet.

Pages: 1 2


Comment and Contribute
(Maximum characters: 1200). You have
characters left.