DX Spectrum Reviews

We use this solution for monitoring both service provider networks as well as customer WAN / LAN / VOIP networks, including all kinds of SNMP-based edge devices.

The key solution to be solved is the correlation between all types of messages from all devices. We are receiving more than 1,000,000 SNMP messages a day across many types of domains.

Unifying the solution within our organization created a standard way of working and integration. We needed a centralized redundant solution for all of our domains, which requires an SNMP-based monitoring tool.

We were able to standardize the internal processes across all internal departments, resulting in almost an elimination of non-standard process flows through our organization.

We were also able to standardize by cross-learning from all teams on how we should configure the monitored elements, align the configuration of the monitoring application, and use the solution such that it created a common understanding of the best practices.

By implementing the automatic service incident, a very strong closed loop is created in the monitoring of the domains.

The topology correlation for layers one, two, three, and four significantly reduces the number of false positives (>98% ratio). By using Spectrum, we did not need to configure the network knowledge about redundancy. Rather, it learns the latest correlation between the monitored elements automatically.

By adding the alerting from the Broadcom performance management tools, a comprehensive list of alerts is created.

As a service provider, we added views for our customers to inspect their sub-domain in our whole network, which reinforces a high level of trust within the relationship to our customers.

This solution is missing the in-depth SDN correlation due to the late arrival of Spectrum VNA features and supported SDN networks. The various setups of the SDN networks are not always supported (yet) by the Spectrum VNA engine.

Integration with non-Broadcom AIOps solutions is a known area. We want to make our own choice for the AIOps solution and do not want to be forced to use the Broadcom OI solution by default.

For our size, a redundant based docker platform should be supported for large scale environments with more than 80,000 devices. This will have a very strong positive impact on the effort we need to spend in maintaining our large scale Spectrum solution and the related cost. The time to market for the new Spectrum solution will be reduced dramatically if this becomes available.

We have been using CA Spectrum for more than 15 years.

Stability is good, especially for large scale location redundant solutions with more than 80,000 devices in a single cluster.

In general, the location-redundancy with automatic failover is a myth, except if you are using Spectrum. If you setup spectrum in a redundant setup across 2 location (80 km in between), you can have a automatic fail over time within 10 seconds. This simplifies the maintenance of your setup a lot as well: any component can be switched off for maintenance purposes. The redundant instance takes over within 10 seconds.

Scalability is very good.

The support depends on the complexity of the problem. Because our own knowledge is quite high and our environment is quite huge, problems can be very complex and time-consuming to solve.

We used several solutions prior to this one. The reason we switched is that the combination was causing a problem and we needed to standardize.

You do need a decent level of knowledge to roll out this huge scale solution.

Small, single location-based solutions for 10,000 or fewer devices are relatively simple.

In our experience, the OOTB settings are very usable.

We did implement this using our own in-house Spectrum specialists, which do have knowledge that is on the same level as the first line support at Broadcom.

Our ROI is realized through better NPS and a smaller labour cost.

In general, the license cost will be about 30% of the total TCO for this tool (hardware/support team, OS costs, and OS management). It turned out to be cheaper than other solutions, even those in the public domain.

We evaluated IBM Netcool, different public domain-based SNMP solutions, HP OpenView NNM, and SolarWinds.

We hope that the speed of the improvement and product growth will soon again be at the same level as when this was a CA product.

We actually service providers for CA Spectrum. If we create a solution for a customer with this type of API, we use CA Spectrum to monitor this API.

I have found the cross-analysis feature to be the most valuable. The many alerts you get have an impact on the connectivity, so you need a very good correlation for layer 1, layer 2, layer 3, and layer 4, layered at the understanding of the technology, which locates the spectrum. It's really unique in this type of solution.

We have been using CA Spectrum for over 15 years, I think.

The stability is very good - the best we've seen in the market.

It is very scalable. We scale to up to 50,000 devices or so. That's the sizing we usually pulse. And we haven't had any issues so far.

We thought that because we are not beginners anymore, we have very high expertise ourselves, so we usually take a second-class support approach or we fix it ourselves. But when it's more complex, it takes a little bit more time.

For us, the implementation was quite complex but it's because of the large number of different environments we're dealing with. So it's not the tool, it's the domain expertise. We need optimized implementation.

Time for deployment really depends on the size of the domain. It can be done in half a day, or it can take you up to eight months or even longer. So it depends on the domain complexity. And then it's not building an application itself; you have to design first, and that is the biggest chunk. It costs you eight percent. So if the design is done properly, then the building is already configurated. There are still a lot of app ports that can be done to help us out.

We going more for a solidified network so we need some improvement there, based on the current level of support for our network. And a more detailed integration with NetFlow data is important for us as well. I also feel that the CIS lock-based correlation needs to be developed as well. So on a scale from one to 10, I will rate CA Spectrum an eight.

• Global deployment for AIG NOC
• Deployment in customer networks, as well as multi-tenant deployment at Affiliated Computer Services (ACS) 
  

The Spectrum tool improved our network assurance levels for our business units. However, the CA Technologies sales team destroyed their relationship with our business units.

• Monitoring
• The dashboard 

It needs better integration with other CA products.

We migrated all monitoring, which was previously monitored by the Applications Manager for CA Spectrum/CA eHealth.

All networks (or network equipment) are monitored through CA Spectrum. However, the service monitoring part of the tool is not the best solution.

For networks:

• CA Spectrum
• CA eHealth

For applications:

• CA UIM
• Zabbix has always supported us in custom monitoring, scripting, etc.
  

OS monitoring needs to be better developed, as well as their services, e.g., cluster monitoring, URLs, etc.

The primary use case is to monitor networks.

It is easy to understand and determine when and/or where the network is failing. 

All the features are working fine.

Make it easier to certify devices. 

Monitoring. We set it up so that other people can watch everything and let us know if something goes down, or processing needs to be restarted. Then, sometimes, it just does that on its own. Air conditioner overheating. Stuff like that.

For the most part it has been good. There were snags in the beginning, learning curves, and the like, but it's relatively easy.

The monitoring just comes to us: "Oh, there's something wrong with that machine." It tells us. There are some 50,000 machines or so, all doing different things. And if they go down we hear about it.

It's improved things because we know when something's down and we know when something needs to be taken care of and when not.

The fact that I don't have to sit and watch things. They get monitored, and then I hear about them and take care of them as needed.

If they could interact with the MIBs of vendors better, and have a lot more pre-loaded ones, that would be amazing for us right now.

It's up most of the time. It's good. At first there were a couple snags here and there, but lately, it's been great.

One issue, after two weeks, we had to pass it up, escalate it, suddenly, and the next person went and solved it. Most of the time it's been solved or we've talked to engineers. Most of the time it's been good. No one's perfect.

There were problems with it going down, or generating extra tickets. But mostly, that got worked out after a little while, with tech support and us going back and forth getting solutions to the problems. It's been great recently.

What has surprised me most about CA has been the inner knowledge of some of their techs. I had no idea what was going on and they were like, "Hey, we got it."

It's great. You can just keep adding stuff.

I would say it's a lot like other tech support. Some of it is great, and some of it is unreasonable. The ones that know their stuff, know their stuff. And the ones that are learning, are learning.

A couple other solutions. It cancelled some of those out. 

We switched because it was a bigger thing. We swapped so we could have support for just one monolithic thing, as opposed to a lot of little things. 

It just had more support, we could call somebody. It was very complex business software. We probably still don't use 40% of the solution at this point.

I would say mixed bag.

We wanted to make it so it was automated with a text file, so we didn't have to watch the little bar the whole time and answer those questions. We wanted all the configuration in one little file. So we had to figure out where that was and how they do that. Once that got done, then automation of getting it deployed to new environments, if we need to, is very fast. We just change a line or two in the text file and say, "Do this," and walk away. It's great.

My most important criteria when selecting a vendor are

• knowledgeable tech support
• reasonable forums
• documentation.

I give it an eight out of 10 because it's not perfect, but it's better than a lot of what's out there. There is still a lot of work you need to do on it. Even though it's a vendor product there is still a lot of support you have to have to get certain things. 

Again, we have a very diverse environment; Cisco stuff, air conditioners. To get all that to work to it's full potential with this product, monitoring-wise, is work. So if there was more interconnectivity already in it that would help. For instance, we had devices that were added six months ago that weren't operating to their full potential. Then we would realize, "Oh, this one needs to be done." So we have to run these end processes. Again, the are a lot of devices. Not all of them are doing this, but enough that we have to sift through them, manually, and get this one working and that one working. So that's why it's not a 10.

In terms of advice, I would tell people to load all the MIBs before you add the devices. Literally.

It helps our NetOps group actually handle alarms in a way that lets them see the bigger picture of those alarms, and how they might affect our services. It helps us communicate information about the network state better to services that might be impacted by a specific network condition.

Spectrum allows us to have a holistic view of our network architecture. We have a pretty heterogeneous topology at U of M, we're a half Cisco, half Juniper shop, and we have multiple layers to our network topology. So, it's really important for us to be able to do that topological map, and be able to visualize the network state at any given time.

Spectrum is interesting because it's a super-mature product for CA, and it works really, really well the way it is. In terms of new features and functionality, I feel like there has to be a transition there. The Spectrum OneClick is a Java-based client, and that's aging. Really, before any new feature integration, I'd love to see a comprehensive rebuild of the UI.

It's pretty stable for us. We have, not a highly available implementation of Spectrum, but we have an active standby situation, where we have an active SpectroSERVER and a standby SpectroSERVER and an active OneClick and a standby OneClick running all the time. So it works out pretty well that way.

As the kind of enterprise that straddles the line between telco size and enterprise size, it scales for us, because we're not all the way at telco yet. Maybe one day.

Pretty good. They're super responsive. They have that four-tier system and that works pretty well, because if we have a question, we can ask it at a lower priority and it will still get answered. If we have something where our hair is on fire, they'll call us right away.

It could be a little bit better, to be honest. The upgrade process could be smoother. More of the steps around upgrading could be automated, I think.

When selecting a vendor, the most important consideration is product; it has to be product and features.

I'd give it an eight out of 10 right now, because it does what we need it to do. It could go an extra 20 percent somewhere.

Fault Domain isolation is the primary use case for our teams with this tool.  Once configured, it centralizes alerting on conditions that would require an experienced NW engineer to investigate at the command prompt.

This tool provides excellent Fault Domain isolation when properly instrumented and configured, allowing quick action on links/routers/switches/etc.

Easy navigation from initial alerts to a full topology and detail on the Network infrastructure and it relationships is the most valuable feature

The configurations are still XML-based and require a good deal of coding to setup each object for monitoring.  Alerting is yet more coding, and relationships are more coding... In a drag-and-drop world, this tool is in need of a bit more than a make-over. 

In house