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

By Lisa Phifer

September 24, 2008

Discovering devices

Motorola MUs have agents that auto-register with the MSP. However, network infrastructure devices must be discovered by the MSP using SNMP v2c or v3 (for WiNG products) or the built-in Symbol Entity Mobility Manager (for legacy products). We added our test networks to the SNMP Network Discovery Portlet (below), supplying public IP addresses, port numbers, community strings, and parameters that determined how often and persistently polls were repeated.

Fig32-Discovery_sm.jpg

Figure 2. SNMP Network Discovery. (Click image for larger version.)

SNMP discovery is a network management staple, and the MSP's implementation works much as you might expect. Note that networks must be identified by IP address or range—we'd like an option to supply dynamically-addressed hostnames (increasingly common for small ROBOs).

Discovery can be auto-repeated at intervals (e.g., daily) to spot missing or new devices, including Motorola fat APs (e.g., AP-5131), switches (e.g., WS-2000), and the thin APs (e.g., AP-300) actively controlled (adopted) by those switches. A MAC ACL is checked to detect unknown fat APs only; true rogue detection falls to other suite components (WIPS and/or RFMS).

New devices can optionally be auto-mapped into specified sites, whereupon pre-defined configurations, firmware packages, and event/polling policies can be applied to them. Because the MSP is fundamentally a LAN manager, all devices are labeled by MAC address. Fortunately, a .csv file can be imported to add user-friendly asset names. Unfortunately, we had to repeat that import after each MSP restart or thin AP adoption. Getting assets names directly from each device is expected in a future release.

Organizing devices into sites

Once devices are discovered, they remain in the MSP's asset inventory forever—or until a retired device is manually deleted. To help you sift through and manage large device populations, the MSP provides the Mobile Infrastructure Portal.

This hierarchical tree presents your entire mobility domain, organized by type, IP address, or group affiliation. Here, one can easily search, collapse, or expand tree branches to find devices of interest. Events, monitored stats, configuration status, and firmware versions can be viewed for any selected device. For example, we mapped our discovery results into two defined Sites: CS_Branch, with a single AP-5131, and CS_Lab, containing WS-2000's and subordinate AP-300's (below).

Fig33-SiteList.jpg

Figure 3. Mobile Infrastructure Portal – Site List

Multi-level branches can be created in this tree by assigning hierarchical site names (e.g., region.city.office). Before discovery can map devices into sites, sites must be imported from .csv files or added individually through the Admin Portal.

Sites control how the MSP will use FTP or TFTP to manage each device. As we shall see, many MSP tasks are conducted using SNMP and file transfer. A small network might co-locate one FTP server with the MSP. Larger networks are likely to use distributed FTP servers--for example, an FTP server hosted at each remote site, used by all devices at that particular site to store backups and supply new firmware.

Each site must be bound to an FTP server's public IP (accessed by the MSP) and private IP (used by managed devices). To accommodate this, we poked holes through Internet firewalls to permit inbound SNMP, FTP, and HTTPS. When reconfiguring dynamic IPs became a pain, we re-pointed our sites to an FTP server on the MSP itself. Had we been deploying a production network, we would certainly have secured all MSP traffic over site-to-site VPN tunnels instead.

The Mobile Infrastructure Portal also lets you sort devices based on pre-defined or customizable groups. For example, we created a "CS" group to filter all active devices and list only a chosen few, based on current attribute values (below). These static or dynamic groups provide a flexible, easy way to "drill down" to any arbitrary collection of devices. The Infrastructure Portal can then be used to start management jobs, apply event or data profiles, view alert lists, or generate reports on the entire group.

Fig34-Group.jpg

Figure 4. Mobile Infrastructure Portal – Group View

Maintaining software

For example, the MSP can be used to update the software or firmware running on a single device, all devices in a site, or an entire group of devices.

By selecting the Infrastructure Portal's Software tab, one can view currently-installed firmware versions (switches, APs), software versions (MUs), and update job status. For MUs only, this tab also displays Hardware Inventory details.

Software or firmware updates can be initiated from here. It's even possible to define one job that updates many diverse devices to minimum acceptable versions, scheduling that job to run immediately or a more convenient time. Job status then shows whether and when the update was completed, flagging any errors that may have occurred.

We do not use Motorola MUs in our lab and thus did not exercise the MSP's Software Package Portlets. Companies that do may wish to create "Rapid Deployment Profiles" to auto-provision barcode readers. (Readers scan a barcode containing update instructions and contact a designated FTP server to download new software.)

We used the MSP's Firmware Package Portlets to upgrade our AP and switch firmware—both for testing and to fix a bug in our WS-2000. Before installation jobs can be created, firmware packages must be created. To do so, we used the Resources Portal to import WiNG firmware files, creating Packages that bind files to applicable device models, prior firmware version(s), and target version. After a Firmware Package (or Bundle) is created, it must be uploaded to the FTP server for each site.

Once these pieces are in place, the firmware upgrade (or downgrade) can be initiated from the Infrastructure Portal's Install Software Package Portlet. When a firmware install is started for a group of WiNG devices, the MSP contacts each device at the specified time, verifies the current firmware version, and (if requirements are satisfied) tells the device to upload the firmware from an FTP/TFTP server. If a device cannot be reached, the MSP will continue trying forever or until a specified timeout occurs.

Fig35-Firmware_sm.jpg

Figure 5. Using the MSP to upgrade firmware

There are far more direct ways to upgrade one AP. This multi-step process is designed for upgrading hundreds of devices at once, ensuring consistency across sites, and circumventing common failures. We successfully upgraded operational devices with the MSP, but could not use it to fix a firmware bug that caused our WS-2000 to go AWOL. In short, automation can take you a long way—especially in very large networks—but oddball cases still require the human touch.

Pages: 1 2 3


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