- 18 Hot IT Certifications for 2014
- CIOs Opting for IT Contractors Over Hiring Full-Time Staff
- 12 Best Free iOS 7 Holiday Shopping Apps
- For CMOs Big Data Can Lead to Big Profits
Network World - Our favorite wireless LAN analyzer from last year (see "WLAN analyzers") now has a distributed version that uses a combination of proprietary access points and notebook-based sensors to help assess an 802.11 a, b or g area. Released last month, we recently tested Version 4.0 of AirMagnet Distributed, which seems to have solved some of the access point problems we found in an earlier version.
The product has an outstanding GUI and covers a breadth and depth of 802.11-specific problem areas for maintaining a dispersed WLAN. A tedious sensor-rollout method, a lack of an integral reporting mechanism and some other rough edges concern us, but overall this is a very good product.
AirMagnet Distributed includes four components: a management server that includes its own HTTP server (AirMagnet recommends dedicating a machine to it); a sensor (looks like an access point); the Distributed Console (a Windows-only application that organizes information from the AirMagnet Server application); and the reporting system.
Although similar to the Newbury Networks' Watchdog system (see "Newbury Networks' WiFi Watchdog"), the AirMagnet Distributed system does not triangulate wireless equipment. Rather, distributed access point sensors are deployed across the network, and can be delineated by floor, building and campus to articulate the physical location of errors or problems.
The system did a fine job of giving us wireless information, with only a few minor problems. Like the other AirMagnet products, the distributed system is a wireless-only analysis product; it won't cover wireline problems without assistance, such as wired protocol analyzers or intrusion-detection system applications.
Initial configuration of each sensor was necessary, one at a time, because each one comes from the factory with the same IP address. Each sensor covers all three 802.11 radio modes (a, b and g). It was easier to use the serial interface on the sensor to update addresses instead of configuring through the Web interface. We used four sensors in our tests, which let us cover 4,000 square feet on a one-floor building. The same sensors also were tested in a five-story building with the same coverage area (4,000 square feet).
The optional reporting software runs on a Microsoft SQL Server (a runtime license can be obtained if needed), and organizes the huge amount of data that the sensors can generate.
The sensors have to find the Distributed Network Management Server through a private network or Internet VPN (anything through a direct route). Once configured, each sensor gets a software update from the management server if needed. Even on a wireless network filled with problems, the amount of data sent to the management server remains low, about a few thousand bytes per minute, per sensor.
Monitoring produces data in two categories: security and performance. The default settings indicate a "worry about everything" attitude, which we liked as a baseline.
We brought up the sensors in a local and VPN-emulated environment (we simulated a remote building scenario, see How we did it). Alerts can be sent by e-mail, Short Message Service, telephone and Internet pages, sounds and instant messaging. We tested all the alerts except instant messaging.
The default settings produced an immediate deluge of information and alarms - even if a network is correctly configured for its feature set. Some of the information is trivial, such as the detection of an 802.11g access point that does not support smooth 802.11b-to-g transition. Many older access points don't do this, and even firmware updates won't help. It's possible to remove the detection of items such as this, so your logs don't fill up with essentially useless information.
The challenge with the system then is to find baselines and "normal" settings for a monitored network. Fortunately, the management console GUI is divided into a monitoring GUI and a policy/management GUI that gives highly articulate, though occasionally ambiguous, settings information about each possible monitoring attribute and condition. Understanding the settings requires in-depth knowledge of how 802.11-based network function. The ambiguity arises as some settings don't have good default values, because networks are so different.
For example, it is a good idea to watch for access points that go offline. It means there is a possibility that an area is not served, because an access point unavailable, it is rebooting, or it was nefariously substituted. There are many reasons that an access point goes offline, from power problems to people or objects interfering with the sensor's ability to detect a signal. For this reason, sensors need to be placed where they are unlikely to be blocked, to reduce false positives. This requires some fine tuning and periodic adjustment.