Review: Motorola Mobility Services Platform (MSP) (RF Management Suite, Part 3 of 4) - Page 3

By Lisa Phifer

September 24, 2008

Ensuring configuration compliance

The MSP applies these device grouping and job dispatch techniques to manage configurations, from updating parameters to checking compliance to creating backups.


Here again, the MSP isn't the easiest way to configure a single switch—although you can always click the MSP console's device GUI cut-through button to perform a task directly. Rather, MSP jobs automate relatively complex workflows. Consider configuration changes made using Configuration Templates and Variance Files:


1) Use the Infrastructure Portal to select an "ideal" device and export its config.

2) Edit the config to create a full or partial configuration template.

3) Use the Resources Portal to import that customized template.

4) Use the Infrastructure Portal to select a target device and export a variance skeleton.

5) Edit the skeleton to supply values for templated parameters (e.g., _#IPADDR#_).

6) Use the Resource Portal to import the completed variance file.

7) Use the Infrastructure Portal to select device(s) to be configured and apply both the configuration template and the variance file as shown in the figure below.




Figure 6. Using Configuration Templates and Variance Files

(Click image to view larger version.)


This workflow clones the configuration of a representative device (the template) and supplies parameter values unique to each device (variances). In the final step, the MSP effectively merges the two to create new configuration files to be deployed to every device that requires a similar update. Like software jobs, configuration jobs can be scheduled, approved, monitored, canceled, and restarted as needed. To manage MSP/network load, options limit the number of updates attempted simultaneously.


It took awhile to get the hang of this workflow and the inter-relationship between all the affected Portlets and files. It's possible to simplify the process—for example, hand-crafting a partial template and corresponding variance file. But this is best viewed as a "power tool"—i.e., overkill for simple one-off changes; indispensible for major updates.


Behind the scenes, the MSP interacts extensively with devices to carry out configuration management tasks. Gartner estimates that 90% of successful WLAN attacks occur due to misconfiguration. Those configuration changes can occur for many reasons: a well-intentioned tweak by a local admin, an accidental reset to default, or a temporary but forgotten test change. In all of these cases, detecting the change is the critical first step to taking the right course of action. That's where MSP Configuration Compliance Monitoring comes into play (below).





Figure 7. Configuration Compliance Monitoring

(Click image for larger version.)


When this option is enabled, the MSP polls all active devices to spot changes that might otherwise go unnoticed. First, it uses SNMP to periodically get a configuration update counter. If incremented, the MSP uses SNMP to ask the device to upload its config file to the site's FTP server. The MSP then downloads that active config file and compares it to the last MSP-saved config for that device.


If differences are detected, the MSP admin can review changes before accepting or rejecting them. Accepting over-writes the MSP's saved config, while rejecting causes the device to be restored. Imagine trying to accomplish this check manually for just one switch—and then multiply that effort by 100. Here, it's very clear: savings could accumulate quickly. We relied on this feature more than any other during our test.


Event Monitoring

NOC staff responsible for surveillance can also use the Mobile Infrastructure Portal to keep an eye on Health and Events.


Alerts can be viewed for one selected device or for all devices within a site or group. Alerts can also be filtered by device type, severity, and time period – for example, show me critical alerts for switches during the last hour. As in most surveillance systems, administrators can take ownership of alerts, mark them as resolved, or clean old alerts from the database. Policies can also be configured to trigger event-escalation actions, like launching a script or sending email, SMS, or SNMP trap messages (below).



Figure 8. Health, Event, and Status Monitoring


In Moto-speak, "Events" correspond to SNMP traps sent by devices, signaling incidents like deviceUp and deviceDown. "Health" alerts are triggered by data collected from the device based on Event Policies—for example, deviceDown changes Health to "Warning" while deviceUp makes no change. And then there is each device's summary "Status," depicted as colored dots at the top of the Infrastructure Portal.


We felt that MSP Health and Events overlapped a bit, creating "duplicate" alerts that required more effort to clear. We also ran into occasional apparent contradictions, like the "Critical" status AP with no Events or Health alerts, and the AP that remained "Good" a month after being removed from service. Confusingly, fat APs generate Health alerts and Events, while thin APs generate Events only (Health alerts are viewed at the Switch level instead). And when we applied an email action to our CS sites, we received a flurry of daily alert mail about every site known to the MSP.


In fairness, Event Policy and SNMP Trap tuning might have mitigated some of these problems—but probably not all of them. In a very large network, alert correlation becomes essential, but outputs must also be intuitive and reliable. Based on our test experiences, MSP monitoring could use more polish.


Data collection

Those interested in performance management will want to read our upcoming review of RFMS, the Management Suite component dedicated to real-time and statistical RF monitoring and analysis. RFMS is tightly integrated with the MSP RF Management Edition and can be launched from any MSP-displayed Site or Event.


To do its job, RFMS relies on performance data collected by the MSP. MSP Data Collection Profiles identify sets of SNMP attributes to be periodically polled and recorded. The MSP supplies a number of canned profiles, appropriate for different kinds of devices and attributes. For example, all switches are polled for default attributes for WiNG and legacy switches, while all APs have their own set of default profiles. Some canned profiles collect "static" attributes that change infrequently, while others are used to poll "debug" attributes at a rapid pace for trouble-shooting.


Custom Data Collection Profiles can be added through the Resource Portal, and default profiles can be refined by checking/unchecking individual attributes. Once defined, profiles can be applied at various points in the Mobile Infrastructure Portal hierarchy, along with specified polling intervals. For example, the following figure shows Profiles applied at both device type and group levels.



Figure 9. Data Collection Policies


Note the profiles cannot be directly tweaked for one device—you must go to the Resource Portal and create a new profile to make changes. Like Event Collection Profiles, Data Collection Profiles can also trigger defined actions. But Data Collection triggers are based on logical statements about polled attribute values—when the condition is true, the action occurs.


Data collection obviously generates load on the polled device, the MSP, and the network in between. As such, it is prudent to spend time pruning the MSP's canned profiles and selecting collection intervals sensible for each installation. The MSP provides plenty of raw material to work with here, but beware that these SNMP attribute lists are lengthy and not self-explanatory. Our advice: start with long collection intervals and apply "fast" debug profiles sparingly. For ad hoc debugging, use the Collect Now button instead of configuring very short intervals.



MSP Portals generally offer near-real-time displays for on-going management tasks—for example, recent job status lists, current health alerts, and last-polled attribute values. Some historic information can also be obtained using MSP Reports (below). A few canned reports are built in, but custom reports can also be created here. As for other tasks, Reports can be generated about one device, an entire site, or any group of devices.




Figure 10. MSP Reports


In our view, the MSP is a network management workhorse when used by itself. It seems to do a reliable job of automating large-scale maintenance and configuration workflows. Because the MSP provides a single-point interface to so many different devices and tasks and attributes, education and experience are required to tap full potential in these areas.


Although the MSP centralizes event monitoring and data collection, these tasks have a tendency to create too much information. Here, the MSP either delivers simple summaries or raw data—there's little middle ground in the MSP itself. However, RFMS pick ups where MSP data collection ends—think of MSP as the collection engine, but RFMS as the dashboard where analysis outputs are viewed. Similarly, the MSP gathers WIPS alerts—presented as "traps" about the WIPS server—but WIPS must be used to drill into any security alert. In those areas, the MSP plays a centralizing role but relies on other Management Suite components to add value and "deliver the goods."


We hope the occasional process freeze and spurious event we encountered will disappear in future releases—although frankly they could have been caused by VMware, the laptop, or MSP software. Motorola's remote test environment gave us a bigger sandbox to see the MSP in action, but it wasn't representative of the stable platform one would establish for a production MSP.


As the MSP matures, we also expect to see a few refinements. Most notably, the ability to define per-user resource views would help cut large networks down to size and make the MSP accessible to users with limited rights and responsibilities. But just keeping up with new Motorola infrastructure devices—in the WLAN arena and perhaps beyond—will be a fairly sizeable task. Tackling that challenge is a good reason to manage large, diverse Motorola "mobility domains" through a central unifying console like the MSP.


Lisa Phifer owns Core Competence, a consulting firm focused on business use of emerging network and security technologies. With over 25 years of experience in the NetSec industry, she has been involved in wireless product and service design, implementation, and testing since 1997.

Pages: 1 2 3

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