Thinking of deploying Prizm

Hello all,

I am thinking of deploying Prizm in our network. We currently have about 35 AP’s (2.4 and 900), some Canopy, some Cyclone. We have just over 1000 users.

What do those of you who run Prizm think of it? Does it help your overall productivity? Does it help in diagnosing and resolving issues? We are getting ready to start selling VoIP service over our wireless network, so I would like to get some more visibility into the network and hopefully isolate and diagnose issues quicker and in more of a proactive manner. Does Prizm seem to help you all in doing that?

Finally, on the bandwidth and authentication side of Prizm, does it control the bandwidth by utilizing the settings in the SM itself, or does the Prizm server have to sit in-line to control the bandidth? Our network is pretty spread out, and although it does all aggregate back to one location, I am very hesitant to put anything in-line as a possible point of failure.

Thanks!

Read the forums a little bit on suggested alternatives. I would say unless you need Prizm for lite module floating licenses, then avoid it. It’s extremely buggy and I’ve been far from satisfied since deployment.

We’re only running about 9 APs and 300 SMs.

eagle_tech wrote:
Hello all,

What do those of you who run Prizm think of it? Does it help your overall productivity? Does it help in diagnosing and resolving issues? We are getting ready to start selling VoIP service over our wireless network, so I would like to get some more visibility into the network and hopefully isolate and diagnose issues quicker and in more of a proactive manner. Does Prizm seem to help you all in doing that?

Finally, on the bandwidth and authentication side of Prizm, does it control the bandwidth by utilizing the settings in the SM itself, or does the Prizm server have to sit in-line to control the bandidth? Our network is pretty spread out, and although it does all aggregate back to one location, I am very hesitant to put anything in-line as a possible point of failure.

Thanks!


Prizm:

Pro:
    Visible metrics

    Supported by Motorola (?)

    You can enforce settings/make changes to multiple radios

Con:
    Runs in Java (badly and slowly)

    You might expect Moto to be able to provide you with better metrics than rolling your own would allow. You'd be wrong. I have been waiting for AP side rssi/jitter metrics for the SMs forever, and still we wait.

    Very cumbersome server-wise since they require x-windows.

    They will only support RHEL, despite CentOS being binary compatible.


That's the short list of my thoughts on Prizm.

Prizm does not need to be between the radios and the internet. It manages the bandwidth parameters built into the radios.

I just “evaluated” prizm myself. Actually for like the third time. We had a staff change and I needed a way to make global password changes.

In my opinion, Prizm is a horrible product. First, you would think that when you buy a product, it should install in a matter of minutes. The prizm install is point and click, but during my three trials, going the through install aboutg 15 times using all SQL and the included Postgresql, the product has never worked and always had to tweak configuration files and troubleshoot cryptic messages.

After getting it installed, you realize the interface is klunky at best, and uses java. (Why do you always hear great things about java? Every java application I’ve ever run has had problems, and is horribly slow.)

Then as you add devices you realize that prizm missed 5% of your AP’s, (you have to be sherlock to find out which ones), doesn’t detect all of your subscribers, (and there is no “hey you missed one” button), and trying to even do simple things like setup notifications when a device goes down is a 50 step process. Oh, and look, I just applied a new password and SNMP string to a CMM, and now I can’t get into it. Oh, it’s because it now has this as the password: ûÙ~wlκ›Â

Can you script SNMP queries? That’s a potential solution that we use. You could also try CNUT, at least it’s free.

Prizm is not without its quirks. When we first deployed with version 2.x I was very disappointed. We had to use it though because we were using the now discontinued Lite radios. The latest version (3.1 patch 6) is a LOT better and has come a long way since the 2.x versions.

One thing that Motorola hasn’t really figured out is how to synchronize the primary and redundant server databases. They leave that up to you. That and not supporting CentOS I think are my two biggest “dings” against Prizm.

Motorola tech support for Prizm has gotten better. I think they’ve brought more of it in-house. They used to outsource it to another company here in the US.

You don’t have to run X Windows to run Prizm. There are console tools that you can use to installation and configuration. If you must run a GUI, why run X? Why not run Xming on an XP workstation and run your X applications that way?

One thing I like about Prizm is the ease of updating software. I just updated 37 APs and over 700 SMs without any issues. Also, I needed to tweak the distance setting on twelve 2.4 APs. I was able to push that configuration change from Prizm to all 12 APs at once. I also have a view setup to show me all the radios that are not running our chosen firmware version for deployment.

Another thing Prizm does for us is authenticate SMs. This helps ensure someone hasn’t purchased an SM off eBay or something and connected it to our network. We bulk pre-provision SMs in Prizm prior to giving them to our installer. When he does an install, the radio is all ready to go with a default bandwidth profile and VLAN. This can be a minor headache since we have different subnets at five different sites so he has to know what site a radio was provisioned for. We just mark the SM box with the initials for the site site it’s provisioned for so he’ll know. It’s not foolproof but seems to be working well for us.

I’ve also taken advantage of the northbound SOAP interface. I’ve made it so our billing and user management system updates SMs. This ensures that people are always getting the bandwidth they are paying for and that an SM has a proper description on it. I’ve also made it so we can mark an account as suspended in billing and then have Prizm suspend that customer’s SM. This takes a lot of load off myself as our customer service people can suspend/reconnect customers and make bandwidth adjustments without needing to mess with Prizm itself or ask me. This frees me up to work on other things.


Prizm isn’t perfect but it can save you some time.


Charlie

What do you use for your billing and user management software?

Everything is custom in-house software.

Our user management is all web-based with a PostgreSQL backend. Radius, FTP and POP3 all authorize against this database. Our user management not only manages our wireless users but also our ADSL, FTTx and dial-up (yup, we still have those) customers.

Our billing system is derived from our legacy telephone billing system (we’re a small, independent rural telco). I’m not too fond of it but it works.

I have scripts that pull data from Prizm, our Internet user management system and our billing system all into an intermediate system for analysis and reporting.

At this point, our billing system does not flow through to user management and on to Prizm. We only have connectivity between the user management system and Prizm.

I have processes that run every 30 minutes to update the data in the intermediate database. This is followed by the processes that change Prizm user bandwidth and radio descriptions. Another process runs to suspend or reconnect Prizm users.

If you want, I can share my Perl scripts that update Prizm. They are relatively simple and take values from the command-line. I have a PHP script for each process. One to update the bandwidth, one for the SM name and one for suspend/reconnect. These PHP files make decisions on what needs to be done by comparing data from Prizm against the information from our user management system. From there, the PHP script calls the appropriate Perl script to do the work of making the SOAP call to the Prizm northbound interface.

It’s kind of hodge-podge but works.

Charlie