Plixer Scrutinizer Reviews

My company's clients use Plixer Scrutinizer for network monitoring elements, like CPE, and for a bit of network inventory management.

Plixer Core Platform is a valuable feature and a good software. Plixer Scrutinizer uses NetFlow analysis to monitor whatever is there in a network. Price-wise, Plixer Scrutinizer is not an expensive product. Basically, Plixer Scrutinizer is an affordable product. Plixer Scrutinizer is a tool that allows for customization, especially in scenarios where customers need new product features.

Plixer Scrutinizer is a tool that can integrate with any other brand or product in the market, so it is not an area of concern.

I don't have deep enough knowledge to comment on what requires improvements in Plixer Scrutinizer.

In Plixer Scrutinizer, scalability is an area with minor concerns where improvements are required.

I have been using Plixer Scrutinizer for four months. My company operates as a distributor for Plixer Scrutinizer in the Indonesian market. I use the solution's latest version.

I would describe Plixer Scrutinizer as a solution offering a medium stability level.

Plixer Scrutinizer is a highly scalable solution. Scalability-wise, I rate the solution an eight out of ten.

Plixer Scrutinizer allows its users to monitor more than 100 devices.

My company's clients who use Plixer Scrutinizer are mostly enterprise-sized businesses and a telecom company.

I rate the technical support an eight out of ten.

Positive

I rate the initial setup of Plixer Scrutinizer an eight and a half on a scale of one to ten, where one is a difficult setup, and ten is an easy setup.

I rate Plixer Scrutinizer's price a three on a scale of one to ten, where one is low price or affordable, and ten is high price or expensive.

Plixer Scrutinizer is a tool that is able to fulfill the needs of my company's customers who use it in their environments.

I recommend the product to those who plan to use it.

I rate the overall tool an eight out of ten.

There are two ways of using Plixer Scrutinizer, and I'm sitting on both ends. First of all, it's used for network capacity management. In other words: "Who is eating my cake?" That means: "All my bandwidth is gone. Who has stolen it?", to be clear: "Who is eating it?" What computer is eating my bandwidth?", so that is one use case, and the other use case is security. Plixer Scrutinizer belongs to a handful of products that are able to drill down quite deeply into the network traffic. For security purposes, it is really a very powerful product.

One feature I found most valuable in Plixer Scrutinizer is the very extensive reporting. Reporting is very flexible, though sometimes you need a little bit of support from Plixer Scrutinizer to create custom-made reporting in a very short time. Reporting is a very strong feature of the product.

Another valuable feature of Plixer Scrutinizer is more on the side of how you can implement it. It is running on a virtual appliance or a physical appliance if you have a very large network, but competing systems sometimes run on a Windows platform where you have to install a lot of Windows and databases that are appliance-based. As for Plixer Scrutinizer, you just need to install it with the right specs, and you have a working appliance, and this is a plus for the product.

In terms of additional features I'd like to see in the next release of Plixer Scrutinizer, I can't think of any because you can do some integration with other monitoring tools that are not strong in NetFlow or don't have NetFlow at all. There are also some integration possibilities in the product, plus there are alerts, too. Plixer Scrutinizer is a pretty complete product.

There was a price lift because previously the product was privately owned, and now there is some external capital in the organization, so pricing could be lower, though, for Plixer Scrutinizer, there is almost no competition at this price point.

I've been working with Plixer Scrutinizer for more than ten years.

Plixer Scrutinizer is a very stable solution.

In terms of scalability, Plixer Scrutinizer is an excellent solution for enterprises. It's not really for SMBs. It scales very well for enterprises.

You don't really need technical support for Plixer Scrutinizer, especially for people who are very skilled already with the product, so those people have initiated this or collected this expertise a long time ago, for example, people just evolved with the product while using it. I suggest and advise you to get training one to two times per year, for example, a two-hour session about the new features of Plixer Scrutinizer because there are a lot of features under the hood that are not being used.

My company made the switch to Plixer Scrutinizer because it is scalable, compact, and very competitive in pricing. It is also a small company, and not a large company, so you can ask questions about features and won't have to wait ten years before a feature becomes available. Plixer Scrutinizer has a dedicated NetFlow-only team and organization.

The initial setup for Plixer Scrutinizer is pretty straightforward, particularly if you know what you're doing because you need some knowledge about networking and NetFlow.

Basic deployment can be completed within one day, so you can see what traffic is coming into your network, then you can also start using the filters and the reporting. You can see basic results within a few days, and good results within a few weeks.

The money I'm spending on Plixer Scrutinizer is worth the investment because you can use the product in two ways as a capacity management tool for the network and as a forensic security tool. You can use it in a network operations center or a security operation center. You can do both in just one device.

Currently, the license for Plixer Scrutinizer is subscription-based and at a yearly fee. The price would depend on the amount of traffic you pull in. For example, there are several blocks from a 10K flow, a 40K flow, and a 100K flow, and based on the number of devices that you receive the flows from, that's the license, and it is not a per-interface pricing model, so that is a very strong, very competitive pricing feature of Plixer Scrutinizer. Licensing for the product is also not based on the number of storage, compared to some competing products that are priced based on the amount of storage you need, particularly based on the retention and the amount of data. Plixer Scrutinizer licensing is based on the device, and it's more in the direction of $10,000 because, with just  $1,000, you don't have anything.

I'm not an end-user of Plixer Scrutinizer. I'm a partner of Plixer and I can only say what I know about the product. I've used it with technical people because I'm into a high-level perspective of the product.

I'm a reseller or a partner, but my partners are larger organizations, so the total number of users on the appliance itself would be around one hundred.

My advice in terms of using Plixer Scrutinizer is that if you are looking for NetFlow and you really need more than just a simple NetFlow because there are, of course, solutions on the market that cost considerably less, based on if you have one or two interfaces, or if you have multiple devices, but you have a lot of traffic or ISPs, then the product is a must in terms of pricing. If you have only a few devices, core routers, and you have a lot of traffic, then Plixer Scrutinizer is a very competitive product compared to the other products. It's a very stable solution and all the features you ask for are there.

My rating for Plixer Scrutinizer is nine out of ten. I never give a ten when rating a product because I always leave some room even in better products, but this product is close to a ten. Nine is the max for me, in terms of rating.

I'm a partner/reseller of Plixer Scrutinizer and my role supports customers with questions about the product and helps customers with issues, particularly little support issues. Generally,  I ask customers what it is they need and make sure they don't buy the wrong product. I hold a consulting role that ensures customers buy the right product and the right size: not too big and not too small. I'm a value-added distributor with a consulting role.

Plixer Scrutinizer has a few use cases, and the most recent one was looking at network visibility across multiple campuses, so full end-to-end visibility, including cloud. My customer wanted to see some of the cloud apps. Another use case was vendor agnostics, where my customer had a mixed environment of multiple vendors, and Plixer Scrutinizer was key to making sure that my customer can ingest the data that those solutions could put out.

My customers were using multiple tool sets, and through Plixer Scrutinizer, they were able to simplify their visibility down to one management console or one pane of glass. They're now using simplified tool sets.

One of the most valuable features of Plixer Scrutinizer is the reporting, particularly how easy it is to drill down into the reports. Another valuable feature of the solution is its overall visibility. It's great. I also liked Plixer Scrutinizer in terms of deployment time and that it's very simple to set up. Once you get the appliance set up and connected, the customer starts to see results immediately, versus other solutions where that could take a while.

Though Plixer Scrutinizer has network detection and response, it's an area that needs just a little more rounding out. Another room for improvement in the solution is its lack of SaaS offering which some customers were looking for. My company deals in small to medium businesses, mid-market, and some customers wanted the SaaS feature which Plixer Scrutinizer doesn't offer.

What I'd like to see in the next release of the solution is for it to have a SaaS offering because my company also deals with educational spaces and smaller businesses that just don't have the staff that can implement this. If there's either a managed service or SaaS-based offering to just make it a little easier for those types of customers, it would be a great addition to Plixer Scrutinizer.

I've worked with Plixer Scrutinizer for two years.

Plixer Scrutinizer has very good stability. It's been around a long time and its networking visibility tool is fantastic, so it's extremely, extremely, solid.

Plixer Scrutinizer is an extremely scalable solution. It's known for its scalability which was why the customer selected Plixer Scrutinizer.

The technical support for Plixer Scrutinizer was fantastic. The team was awesome. Support was very responsive, very knowledgeable, and not just only on Plixer Scrutinizer, as support was very knowledgeable with third-party solutions as well. Whether it was Cisco, Aruba, or whatever the network was, the support team was very knowledgeable.

Our customers were using either LiveAction or Stealthwatch from Cisco, and they liked that Plixer Scrutinizer had greater visibility compared to Cisco which does well only on Cisco environments. A lot of the clients we have are, given the market, taking advantage of adding HP switches to their infrastructure, so they're no longer single siloed. That was a key feature of Plixer Scrutinizer.

Our customers also used AkenTech and ExtraHop. What made them choose Plixer Scrutinizer over ExtraHop was the price. It came down to pricing because Plixer Scrutinizer only charges by node, so how many exporters or devices customers were taking exports from, while ExtraHop does bandwidth, and that seems to be a very expensive way to do it.

The initial setup for Plixer Scrutinizer was very, very straightforward. As long as you could export flow data off the switches, and point and direct that flow, the only manual process you have to do is set up the switch to export the data. It was a pretty easy process, once everything was aligned. The client was pretty happy with it.

The deployment time for Plixer Scrutinizer was pretty quick. From the time it was delivered and it was set up, it took two weeks, but that was really on the client. Once the client had all the information needed to set up the solution, it was a very smooth and very quick process.

We're a reseller-consultant, but we use their in-house services for implementation. Their engineers were great.

The licensing cost for Plixer Scrutinizer is in the middle. It's not the cheapest, but it's not the most expensive. Its licensing model is based on how many exporters, how many devices export information to the system. Plixer Scrutinizer has different modules you could add such as the security module which would cost extra.

Our customers evaluated LiveAction, Stealthwatch, AkenTech, and ExtraHop.

I have experience with Plixer Scrutinizer, particularly the latest version with NDR capability. I know a little bit about its installation, deployment, etc.

The solution is deployed on-premises. It isn't a SaaS-based solution.

In terms of the users of Plixer Scrutinizer based on my customer, everybody from the network is using it, for example, engineers use it and some security personnel uses it for alerts. It's all been very positive. My customer was able to integrate Plixer Scrutinizer with the current SIEM solution. The network operations team seems to like it, so it's all been positive so far.

I have no idea how many people are in charge of deployment and maintenance, but Plixer Scrutinizer is known to be a very simple tool.

Currently, my customer is using the solution mostly on the network side. Plixer Scrutinizer did announce a security module and my customer is taking a look at that. There are some definite enhancements added to the tool.

My advice to others looking into implementing Plixer Scrutinizer is that if you're running a multi-vendor, multi-network environment, definitely take a look at the solution because it excels in that area.

I'm giving Plixer Scrutinizer a nine out of ten because even if it has some areas for improvement, the overall experience with the solution especially based on the clients I've worked with, has been fantastic.

My company is a partner/reseller of Plixer Scrutinizer.

I use Plixer Scrutinizer for Network traffic analysis.

When comparing Plixer Scrutinizer to NetFlow Analyzers and Microfocus NPS (Network Performance Solution), the features I found most valuable in Plixer Scrutinizer are the ease of access, particularly in the GUI, and the ease of the solution.

The most valuable features of Plixer Scrutinizer are its ease of use, accessibility, and UI.

I would recommend having more data points. Plixer Scrutinizer cannot handle high traffic volumes.

This is NetFlow Analyzer, and the number of data points, or the massive volume of information is stored. There are numerous processes running inside a router. As a result, a massive amount of data is being logged in this Plixer Scrutinizer. 

It is my understanding that when the flows are too high, the solution cannot handle them, and it is not simply a matter of scaling it up. For example, on ACI, you can define Cisco ACI core switches, and it is found that on Plixer Scrutinizer they are unable to handle the traffic volume. 

When I'm talking about a core switch or another switch that has a large amount of traffic flowing through it, the solution is also incapable of handling it.

In terms of data aggregation and storage, while I was not managing it, one of the feedbacks, specifically to this solution. I can't comment further on the technical side of things, but from a user standpoint, the team was only keeping the real-time log for one day. Then, for three days, it switches to five-minute aggregation. It switches to one-hour aggregation for one week. For one month, it will be aggregated on a daily basis, to save space. 

It aggregates the data points and removes the individual real-time data points before reducing the data points to conserve storage. I would suggest an improvement in data storage, or how the data is archived and sold so that enterprises have more room to keep data for a longer period of time with less aggregation. It will be kept for real-time value for a month, rather than just one day.

I've been using Plixer Scrutinizer for nine years, but I haven't used it in the last year.

I don't remember what version we were using because I haven't actively used it in the last year, but it was one of the more recent ones.

In terms of stability, it was good, but I wouldn't say that it was excellent.

I have seen a few crashes, however, it's very rare. While it is stable, there is always room for improvement. But it's fairly stable, and in the user experience, it remains consistent.

The solution's scalability is struggling on devices with a large number of flows.

ACI from Cisco, and not the Data points. Data points are improvements to how data is stored or archived. I've noticed that the solution is inconsistent on devices with a large number of flows, such as core switches for Data centers, or Cisco ACI.

To rephrase, the solution is suitable for a brand router or an internet switch, but it is not suitable for, at least in our environment, a core switch within a data center where the number of flows and communications will be high. From what I understand it is that the solution is not very scalable in a high volume traffic environment with a large number of flows.

This solution is used directly by 50 people in our organization. Most of the users were network engineers.

The solution received positive feedback. The usage was already on a daily basis. No further increases were anticipated or planned, but it was used extensively throughout the organization.

I am not aware of the pricing.

I am not an expert user or an administrator of the solution, and I have not recently used it. 

I am a problem manager. I conduct deep-dive analysis and retrospective analysis following the incident. To determine the root causes, we must examine all of our solutions in the application landscape.

I would strongly recommend this solution to anyone who is interested in using it.

I would rate Plixer Scrutinizer an eight out of ten.

We used this solution for MTA. I am responsible for the network; I would have been the only person using this solution.

As I didn't get it fully up and running, I can't really say what features were best. 

When you download Windows 10 and first log in, it says something like, "Welcome. We're setting up a few things, we'll be right with you. We're going to customize some things and get it going for you." Then, it just loads to a desktop and nothing else happens. You don't have the applications installed. You don't have any customization, it's just a default setup. That's essentially what we had. We had a default setup. We were trying to set up some configuration, but it just wasn't quite working properly.

We couldn't get it set up properly. We had multiple meetings. They apparently noted down what I was asking for, but we just went back and forth, and we just couldn't get the thing to work or configure properly.

Those discussions were with their sales guy and their sales engineer. They set up a demo for me. They were working with me to try to set up some configurations — some customization within it. It wasn't very intuitive. They gave me documentation, that wasn't very user-friendly. They just didn't seem to understand what I was trying to do. So we just went back and forth, back and forth.

It was like calling McDonald's and asking for a cheeseburger, and they give you some chicken nuggets. I'd say, "This isn't working for me. I want a hamburger. You gave me chicken nuggets". I would ask for this and they'd give me something else that didn't make any sense. After multiple meetings, eventually, I was like, "I'm done." Then I started looking at Awake Security and started looking at some other MTA's out there. 

I used Plixer Scrutinizer for a few months. I never got it fully configured. I ran into a bunch of problems and I just couldn't quite get it working properly.

We didn't experience any bugs.

They need better customer service that can help you make the trial experience better.

We had some challenges with the configuration — that's one of the reasons why we stopped using it.

My advice is to make sure you have a good experience during the trial that you set up.

Overall, from my short experience with this solution, I would give it a rating of five out of ten.

The primary use case is all bandwidth utilization.

Our solution is up-to-date. We're using the standard NetFlow v9 and IPFIX with the products that currently support NetFlow.

Scrutinizer gives us an answer. Time to resolution for problems has been reduced, because I now have a tool where I can look at historical data. I no longer just say, "Well, you're going to have to call us when it happens again. Maybe we'll catch it." It's pretty much the only tool that gives me this type of visibility.

The internal reputation of our IT to resolve historical bandwidth problems has 100 percent improved. The general time to resolution has improved by having a tool where we can look and see what is going on, even in the last half hour, with alignment that isn't performing well.

The insight the solution provides as a result of its correlation of traffic flows and metadata is really all that I have, so it is extremely valuable. If I were to give it a number on a scale, I'm probably holding it around a seven or eight, as far as usefulness, compared to my other tools.

We found the solution helps eliminate data silos because we do allow all company access to the product, since it's a read-only tool. We have shown a number of different departments in DevOps how to look at it themselves and diagnose their own problems, e.g., when they're having slowdowns to Azure. We have our express routes tagged to the Scrutinizer product. They can tell when the line is saturated and what's saturating it. This has empowered them to self-police what they're doing on the line, and it reduces the ticket count that we get. This gives us an insight on how to manage the traffic flows. More people can see IT data in real-time without having to ask IT a question and wait.

It is a workflow for the basic troubleshooters to always check anytime someone says there is slowness or a performance loss. You check Scrutinizer for that site to see what it is doing. So, it is in our workflow.

Our biggest lesson from using this solution is how to control and manage Commvault. Our biggest clobber of traffic was Commvault backups. There was a lot of stress on the network as backups ran into the daytime activation hours. We were able to track when and where they were running their backups just based on how NetFlow showed Commvault's usage.

History features are the most useful for going back and looking at when a problem has been reported, anything prior to immediately right now. A lot of it is, if we had really slow traffic over the weekend, and I come in on a Monday, it will not be slow now. So, I have nothing to look at, it's in the history.

The solution helps to enrich the data context of our network traffic. It allows me to see what applications are most in use on a slightly historical basis, going back a day or week at tops. It allows me to tune QoS or traffic shaping around what's being used. It saves me from having to unnecessarily upgrade, if I don't need to.

It is an easy go-to tool.

The visual acuity of how it presents data can sometimes be confusing. It takes a bit for people to spin up how to look at the graphs. It's how the graphs are displayed and how busy the information is. When you first take a glance at anything that's displayed, other than just the single line drawings, there is a lot of information displayed. It can be overwhelming if you're not used to it. In a lot of cases, a product like this only gets looked at when there's a report of a problem. It's not an everyday tool. Thus, most people don't get used to it.

I have been using this solution for five to six years.

It is extremely stable. I don't ever play with it. I have never had to tweak or tune it. We have had to upgrade it in the past when they have made a major architecture change. Other than that, we sort of forget that the box is running, use the GUI, and go. It does what it does. It doesn't crash.

One person is required for maintenance and deployment. There is a backup guy, but all he does is look at my docs and repeats what I do. He doesn't spend any time on it because I don't spend any time on it. If it were to crash right now and had to rebuild it, we would just download a new one and start over because that is how infrequently we touch the product. So, no one probably remembers the database passwords anymore because in six years we haven't had to touch it.

I haven't ever used more than a single collector. So, I've never really tried to scale. My quantity count for device input has always been below a 1,000. Thus, I have never pushed the box to its max.

Out of IT, there are about eight technicians who either configure debt flow on a device or are directly effecting a ticket. After that, we have about 40 to 50 end users that view data to understand their own areas of the network in the different regions, such as Asia, Europe, etc. These are IT professionals, but they are monitoring, not networking. For example, "What's my internet usage? What's my MPLS usage, so I can see how my site's doing?" It's become more of an overview.

We are not really looking to create any new usage. In fact, we've pulled back some of its usage only because we have gone away from traditional MPLS and routers and onto an SD-WAN solution that already brings onboard its own version of the same metrics. Therefore, we've reduced the number of inputs to it, but we're almost topped out there. 

That's pretty much our way in infrastructure. It's pulled back from the use of NetFlow. NetFlow is still being used for most of our major Internet connection points over the globe. It probably still is being used on all of our ties with other vendors, as they're private lines into our company. Also, it can be anything at the data centers that use traditional networking. So, we're not really growing it. It's not really shrinking anymore, but it was. Last year, it shrunk by quite a bit.

We are primarily a retail shop. We have a lot of little stores which used to be part of a much larger network. Those are all SD-WAN now, so they're not seeing anything with Scrutinizer. However, it's still on all of our Internet lines. So, it's pretty stagnant and stable.

The technical support is stellar. It feels like Plixer really has the one product that they're doing, and that's pretty much all they do. They're not overly divested. When you call them, it's almost as if they're waiting on the hook for someone to have a problem so they have something to do. That's what it feels like. 

When I try to contact either Jamie or Jake, it feels like they're ready to start up GoToMeeting within a minute or two of my email going out. It does almost feel like they're on the hook hoping somebody will have a problem somewhere so they have something to do. That's the response level that I get.

The company was using the old MRTG, which doesn't really provide application visibility at all. It's not really a commercially supported product. So, if anything went wrong, it was like, "Well, I don't know how it works." We switched to get onto something that was commercial.

The initial setup was straightforward because I've used the product in a number of other companies. I'm very familiar with NetFlow. For me, it was rather easy. Then again, it could have been really complex and I would have thought it was easy.

There was really not a lot to get it setup. I would give its construction of maps a bit of a ding for complexity. Trying to get maps and lines to show up so people can look at it and understand what they're seeing was a little on the complex side because their little drawing manipulator is not exactly the greatest. It's like using crayons.

It wasn't a hard product to set up. The hardest part was getting the resources out of VMware to get it set upon. But, that's not their fault. A product like this comes in, and says, "I need this much storage." Then, the people that run VMware freak out, "Why would anything need that much storage?"

I was the one who set it up. I came in as the expert. 

I talked to Jamie and Jack directly at Plixer because I already knew them from other jobs. I use them because, as a technical person, I suck at doing reports. So, anytime a boss will ask me for some type of oddball historical reporting on a site, I still go right back to them, and go, "Okay, guys, show me again how this works," because they do it maybe once a year, and we don't have a reseller who does this.

It was probably up and running inside of four hours.

My implementation strategy was just to gain visibility. It was to set up the company's product, send everything at it, and show my employers what they can see. It was to show them a blind spot.

For historical questions, it has reduced time to resolution by a significant amount since we previously didn't have the data. So, there were some problems that never went resolved because we didn't have the data. In some cases, it's just flat out allowed a time to resolution rather than cancelling the ticket. Easily, it is a solid 70 percent time reduction.

It allows us to show as a department that we can answer some technical problems from past complaints, so we look like we are tracking what has been going on in the network rather than its current state. The goodwill that comes out of seeing the IT department as someone who can solve a problem is where the biggest return on investment has come. 

Just for my team of eight, having something that they can look at, and go, "Oh, that's what's taking up the traffic." Now, we have a smoking gun to go address. Was it backups? Was it someone's download? That's another good return on investment rather than, "I don't know. Let's try this." We are not taking the shotgun approach to troubleshooting anymore.

I saw a gap in our visibility, and I already knew what solution would make that work. This solution was something I knew we needed to bring in. Because Plixer is dedicated to the idea of NetFlow, I don't think there is anything out there that could be gleaned from NetFlow that they haven't thought of or built into their product. So, I'm comfortable giving them a leader role in that technology because that is where they're focused.

We did evaluate other products. We had a minimal capital for an expense on a tool, and I was put up against the guy who does all the Voice over IP. They had Actionware's QoS manager look at all of the QoS network-wide and keep it tuned so we were at least flowing the right data for the right reasons in all the right places through and through so everything matched. He wanted a tool that kept all of that in place. I felt that watching the data flow outside of where QoS ran would be a bigger bang for the buck. I won out on this one.

The differences between the two products is that they service a different master. They're not apples to apples by any means. One is just making sure that your policies are uniform and balanced for QoS, not crossed all of your products. Whereas, Scrutinizer is there to show you what your product's actually doing. It can be used for tuning QoS if you wish to, but then you would be doing that part manually. It could be used for telling you how your site has been over the last week or month, as it does capacity planning. It's real easy for the end user to look at it too. It gives them a view so they get that self-help. High level management can build their own views and look at it, whereas nobody else can really look at the QoS tool because it actively changes the network. So, you don't want to give that tool out. Therefore, it really wasn't apples to apples. 

For our business, it was which direction was the right way to go for the money involved to make our department more visible. It made better sense to have this solution than just something that helped our one engineer engineer QoS better. 

Our SD-WAN is not directly a product that needs Scrutinizer to be effective. I would almost consider it a slight competitor. Its internal metrics and tools provide a very similar insight to what Scrutinizer does. It is the only product that I probably have in my entire architecture that doesn't need Scrutinizer to watch it. It watches itself with a little better clarity, but that is only because it knows itself really well. 

Our SD-WAN solution, CloudGenix, is able to do some IPFIX. We don't send it at Scrutinizer, because their data is just as good, and there is no need to duplicate it on the network.

I would strongly advise that you look at selling the tool as a self-visibility tool to other departments and areas of your business. It makes a great internal status page that others can look at. If an end user or manager hears a complaint about something, then they have a page that they can go to, to say, "How's the network doing?" It saves a lot of calls. I think for the tool to be its own internal health selling point is something to not overlook.

I would rate the product as a 10 (out of 10).

Our primary use case is network monitoring, and security goes hand in hand with that. They're two sides of the same coin. From a network-monitoring perspective, we keep an eye on network links at all times, on the bandwidth usage percentage. It allows us to quickly identify what is consuming bandwidth on a link.

On the security side, it allows us to see issues that occur in the network. Someone might be running up a Tor session. Someone might be trying to hack into something internally or externally. Or there might be excessive use against a particular host or a particular port in our host. 

So those two use cases go hand in hand.

It's strictly on-prem. We're a financial organization within Australia and our government regulators say that you must keep all your data, whether it be financial or IP addressing or network related, on-prem. We run a virtual machine with 250 endpoints.

Scrutinizer helps enrich the data context of network traffic. For example, one of our sub-organizations is primarily responsible for stock trading. They use a time-critical stock trading application called IRESS, here in Australia. I believe it's similar to a Bloomberg-based system in the U.S., but it's based across the Australian stock exchange. That sub-organization of ours has people onsite in their Sydney office who may be doing database operations. They might be copying a 25 GB database across the network. We can immediately tell the head of operations there that they've got an issue because this particular person is copying this database from this source to this destination and that this is the reason that all the network bandwidth is being used.

In addition, the insight that the solution provides us as a result of its correlation of traffic flows and metadata is invaluable. As a network engineer, I don't understand how people operate without it. Without that sort of visibility into what's actually going on in the network, you're running blind. There are other very similar tools in the marketplace, but nothing comes close to the Plixer solution.

Another way it benefits our organization is that it gives us the ability to identify faults and rectify them quickly. It allows us to look at the way people operate in the environment. For example, people were moving around between PCs in a hot-desking scenario, with full home-drive sync and full email sync on. That was consuming a lot of bandwidth across the network. I was able to work with our Exchange teams and Windows teams and explain to them that they should turn off the full email sync and do headers only, and that they needed to stop syncing the entire H drive component. Some of our end users had up to 25 GBs on their home drive, so when they're moving from PC to PC in a hot-desking scenario, that's crazy. We could see that they were consuming all the bandwidth constantly on this particular link. I would estimate that we have improved bandwidth availability by at least 25 percent, throughout the entire day. That's the sort of value we get out of the tool. We knew it was happening, but the ability to prove it to the business units and say, "This is what's actually causing the problem," is just invaluable.

Moreover, we previously we had a 1 GB DCI between our two data centers and we could quite clearly see that it was running at 100 percent the entire time. It got to the point, with the backup solutions running between our primary and secondary data centers, that it was never able to catch up. Using that information, we were able to make a case to our business that we needed to increase our DCI from 1 GB to 10 GB. That improved the backup performance and backups were able to complete successfully. The business is able to continue without any worrying about the backups not being successful.

We're very unique within Australia because we have our data sovereignty laws requiring us to have an on-premise control plane. The customers I've been working with mostly use off-prem or cloud-based control planes. Because we'd set up our vSmart/vManage inside our own data centers, it was unique. Only about 5 or 10 percent of their customers actually had that capability. So to be able to give them access to our environment to actually help develop the solution allowed them to move forward, and provide relatively good visibility, visibility which enhanced what came out of the vManage control plane. That helped us to proactively know when SD-WAN topology changes. In the vManage, we knew events were occurring, but the Scrutinizer solution allowed us to visualize that in a graphical format and to show the business how telephony calls or video or business-critical applications are being moved between links, based on the real-time performance of those links.

As a result, the first thing we did — because we had a combination of fixed wireless and fibre — was to go back to our service provider and say we don't want any more fixed wireless. Most of our branch sites were dual MPLS. We did have a sub-unit that was franchised using Ethernet solutions, but our dual MPLS connections were provided by fiber, primarily, and fixed wireless as a backup or alternate link. We could see quite clearly that our data was constantly being moved over fixed wireless due to issues with the way that the radios were deployed or the ways that the radios were tuned. As a result of that, the service provider went back to its fixed wireless division and made them do some work to improve the service.

Scrutinizer has also helped to reduce the time to resolution, especially for network events. Without some sort of application visibility and control system, you have no visibility into what the problem is. All you have is your best guess. Having that recorded data, and being able to play it back and look across time at bandwidth utilization, enables us to show problems to the business and eliminate them immediately. I had it on a big screen next to the operation sections. As soon as something went red, we clicked on it and we understood the traffic flow that was causing the problem. And if it was not legitimate, we were able to go directly to that end-user, because we had it tied into our AD, and tell that end-user to stop doing what they were doing or to do it outside business hours. Now, our mean time to remediation is about five to 10 minutes, maximum. Without using Scrutinizer, we'd be best-guessing for hours on end. When you have a look at, for example, what's going through a router, you look at the percentage usage on the interface. You can't look at per-flow analytics.

The whole package is valuable.

Personally, as a network engineer, the ability to identify what traffic on the link is consuming all the bandwidth at any given time, and provide immediate feedback to the business, is the most valuable feature.

We've also got the advanced reporting on the security side of it, not the NetFlow side. We've always had that integrated into our SIEM solution. It's one of the things you can add on top of what Plixer offers as a base package. It runs analytics over all the NetFlow and then provides signature-based recognition of problems in the network environment and provides that feedback through a reporting mechanism. We've customized it to push that into our SIEM solution.

There is room for improvement around the data that they have on the website about solutions. I understand that putting a particular appliance into any given organization is going to bring its own challenges — and Plixer does do a good job of blogging it — but they should have more templated solutions on their website. Going out and identifying how to do RTP performance with a Cisco router, or how to do application response times in an Arrista data center deployment was where most of the work was. We had to identify the end-vendor's configuration where Scrutinizer worked. They should spend some more time documenting solutions and putting together white papers.

I've been using the product since 2014.

It's very stable. It can go up to a year or two without a reboot. It mainly gets rebooted when I do an upgrade.

During 2015 there were a couple of releases and I had a few stability issues. That was mostly because I moved the database from a Windows appliance to the Linux back-end. It didn't quite sync across. I just deleted the maps and rebuilt them from scratch and that fixed all the problems. That was the only real stability issue we've had across the journey.

We had one upgrade that didn't go as well as it could have, but Anna was able to jump on it with our support engineer and fix it within 15 minutes. It was just a matter of reaching out. They were on the phone within 20 to 30 minutes and got it sorted for us.

We're running 250 reporting end-points across our firewalls, data center switching, the SD-WAN deployment, and our branch and campus switching — all off a VM. If I was going to run any more than that, I would probably look at a hardware appliance or a distributed model.

We don't currently have plans to increase usage, but our organization invests in a lot of other organizations and that's when we would use it more. For example, in 2016 we bought another financial organization and we had to deploy to another 10 branches with 20 appliances, plus switches. It just depends upon what the business requires. I've got good visibility across my entire environment at the moment.

Their tech support is unbelievable. They're really good. I've never been out of sorts for more than 15 minutes. That's a fantastic response time, considering I'm in Australia and they're in the U.S. The guys are mostly in Maine and they jump on after hours to help me out. These guys are awesome and if I've got problems with it, I know that I can reach out and they'll sort me out immediately.

There's no comparison to some of the other vendors I've worked with. I've had maintenance with Cisco and it has taken them nine days to replace a device. It's to the point where I no longer have maintenance of any of my Cisco gear with Cisco. I've gone to a third-party. 

My predecessor made the decision. He's a very security-minded, security-focused individual. Most of the other vendors are providing a solution that looks at NetFlow analytics and that's it. Scrutinizer provides NetFlow analytics of network performance, but also provides security.

We do use Darktrace for a different reason, on top of Plixer. But the advanced reporting from Plixer is providing me more detail than Darktrace. Darktrace is giving us some good PLP stuff, but they are for different purposes. Darktrace is looking for more shadow-IT stuff, where Plixer is looking at more real-time flow and analytics.

Plixer's years of experience in delivering security and network visibility solutions influenced our decision to go with them. They seemed to have a solid solution, out-of-the-box, in 2014. Back then, AVC was not something that was widely deployed. That was pretty much the stone age of application visibility control, especially in Australia. There are still not a lot of people using AVC.

It has a steep learning curve, not because the product is hard to use but because to actually deploy application visibility control, you need to have a fairly in-depth understanding of networks, network flows, and application visibility control. In my case, it was an NBAR deployment, which is the Cisco Layer 7 DPI. You need to understand quality of service and how that actually all ties in. To be able to use the product effectively, you need to be a fairly advanced network engineer.

Once you've got it set up, you can then give that information to the service desk and the service desk can immediately see what's happening, without having to annoy me. Once it was set up and deployed, we were able to give it to everyone within the IT infrastructure, and the service desk, and they were able to find the problems on their own, straight away, without having to deal with the network team.

The initial deployment to get it set up was a matter of a change to include NetFlow export on all my WAN routers and my internet routers. The deployment of the appliance took about half an hour. But it was the going around and configuring all the routers that took up most of the time. With all the configuration it took a very long time. In a production environment, you can't just go around and make changes on devices. I had to go and present the change to the change advisory board. There was all the paperwork associated with a particular change. And then rolling it out across the entire production environment, where I had 80 branch sites that were dual MPLS, and 40 or 60 non-MPLS Ethernet-based connection sites, it took about 100 hours. But that is not a reflection on the Plixer solution, that was a reflection on the way that my system internally works with change and the time it takes to actually do things.

The strategy was that once we got it up and saw flows in there, we then went and deployed it globally on all our routers. Over the years we gradually made changes. Once a year, we sit down and have a look at our quality of service and application visibility control. That's a pretty intensive process of understanding what sort of applications are running in the environment and then categorizing them through the quality of service side of the house. We then look at what we want to be monitoring in detail — in particular, with response time for applications or real-time flows in the environment, and fine-tuning our IPFX policies that are deployed on our Cisco routers. That's a little bit time-consuming, but again, that's not a reflection on the Scrutinizer.

I did it all myself.

We didn't need a great deal of time with Plixer, once we got it up and running. I worked with someone there for about three to four hours who gave me some more information about how to use the appliances properly. Because she was very good at what she does, I was able to get that information and deploy it immediately. It came down to working with the individual vendors' products: Palo Alto firewalls, Cisco Nexus data center switches, Arrista sFlow. I had it deployed on Cisco ISR 2s, ISR 3s, and ISRs. I had it running on the Cisco 9300 and 3850 series switches, as well.

The ability to fault-find and provide business continuity and the speed to resolution has been the return on investment. People can see what's going on in the network. They're not wandering around for two to three hours, not being able to do their job because there are problems in the network. We can immediately see that this person is doing the wrong thing and we can say, "Stop it." Previously, we would have had to wait for that person to finish what they were doing, and that could bring all 2,500 users down for a period of time.

We pay our one-off cost for the licenses, per device, in blocks of 50. And then we pay an annual maintenance fee of about $15,000 Australian, which is, at this point in time, about $9,000 US, for those 250 devices. The upfront costs for the 250-license use, were about $50,000 Australian, which is about $32,000 US.

There is also the cost of the infrastructure, but that's a little bit hidden: the storage infrastructure and computer infrastructure to run it.

The price point is on par with its competitors, but you get more value for money out of Plixer because you get that security focus as well.

We evaluated quite a few, including open-source. The one that came closest was the LiveAction Networks solution, because that's what Cisco recommended at the time. But it was looking at network performance, not security. Plixer was like killing two birds with one stone. It had a better platform for network performance monitoring and it gives you the bonus of security monitoring.

The way that LiveAction displays traffic between devices in a map is probably a little bit better. Aside from that, the level of data that you can drill down to within Plixer is significantly enhanced, compared to LiveAction.

Overall, Scrutinizer has much better functionality.

The biggest lesson I've learned, personally, by using Scrutinizer, is that not many people understand what's going on in their network with their own applications.

My advice would be more around the equipment you're deploying it on, the exporters. Plixer is very easy to set up and get running. If you're going to be running more than 30,000 or 40,000 flows, go with the hardware version. But, be aware that IP effects exporting on Cisco devices; it can take a heavy toll on CPU.

For maintenance, it's pretty much just me. It's pretty easy to keep up and running. My team can do it, but I'm the guy who handles it. There isn't a massive overhead to manage it. The things that took a little bit of time were fine-tuning data retention, policies, etc., based upon A) what the business needs, to be able to fault-find, and B) the storage availability, based upon the number of flows in our environment, because we're running up to 30,000 flows per second.

We have about 30 users across the whole of the IT infrastructure. There are five primary users within the network team, plus me. Then we have the rest of the infrastructure team, which has about 15 people, and we have the service desk personnel, where there are 10 to 15 users.

I honestly don't think there are many areas where Scrutinizer could be improved. It's a pretty robust, out-of-the-box solution. When you compare it to other AVC solutions for monitoring purposes, it's fairly feature-packed. To use 100 percent of the features is almost impossible. For the first few years, until I became comfortable with the solution, I was only using 10 to 20 percent of them. Once I understood, and spent some time working with the team at Plixer, and they gave me some good feedback on how I could use this in our environment, that's when I started using 50 to 60 percent of the feature set. I still don't use 40 percent of the features because I just don't have a need for them in my particular environment.

I've been really happy with it. And because they're such a well-meshed organization, I've had access to everyone from my sales rep to the head of support to the VP to the CEO of the organization. I've talked to all these people over the years. They're very customer-focused. It helps you to be able to achieve your goals. As a network engineer, you don't want to be whining about your monitoring solutions. You want to be using them to worry about the problems that are happening in the network. They've taken the concern about monitoring off my plate and allowed me to focus on my job.

We were looking for something that would tell us what our bandwidth utilization is. My security guy uses it every once in a while to see if an IP address or URL has ever crossed our network. He can get that kind of information from a security standpoint. I know there are other uses that we really haven't used it for, but our primary still remains the bandwidth utilization. 

Whenever it happens that my first responders get a call about a problem at one of our 16 locations, it's one of the primary tools that they'll grab to see what it's saying. 

Currently, we have Plixer deployed on-premise. We have just recently moved some of our servers to the cloud, and I am looking to talk to them in the next month or two about setting up monitoring on the cloud, because we are on AWS.

I once got a call from one of my branch operations and they said that the teller line had just frozen up and they just flat were not able to do business. It just wasn't working. I said, "Okay, well let me do some troubleshooting." I grabbed Scrutinizer and looked to see if, in fact, the bandwidth was being slammed pretty hard. It revealed, really quickly — within a couple of minutes after I started troubleshooting the problem — that somebody was running a video capture across a very slow link. I was able to find out who the employees were, via Plixer. I quickly called the lady who was in charge of our security cameras, and said, "Wait a minute, you're taking the whole place down. Can you turn it off and let me see if that fixes it?" She said, "Oh, I'm sorry." She turned it off, and as soon as I saw her turn it off in Scrutinizer, they were back in operation.

It has definitely helped to reduce time to resolution for network and security events. This is the tool that I grab first. It gave us better than 50 percent accuracy when we started using it. My boss was a little bit skeptical and I was a little bit skeptical. I told the sales team at Plixer, "We'll go ahead and purchase it for the first year. If everything that you guys are telling me is true, then we're going to be really happy with it." And my boss and I have been very happy with the product.

Whenever I have Microsoft SQL or even workstations that all of a sudden start running amuck, taking way more bandwidth than what they normally should be taking, I can usually pinpoint things very quickly. I've got to be able to see what's going on in the wires, so, I call Scrutinizer my "Superman X-ray vision" for looking at the wires.

It's agnostic as far as what your network gear is. As long as it supports an sFlow, JFlow, NetFlow, some kind of flow monitoring, Plixer will support it very well.

It also facilitates the enrichment of the data context of network traffic because you get a very clear picture of what's going on across your wires. I gave my managers the following example: If I can't see into the wires regarding what's going on across them, then I can't really manage them or troubleshoot things. Scrutinizer allows me to do a little bit of both. It allows me to analyze things — not to the point of being a packet analyzer; it doesn't do that and that's not its function — and can give me an idea and point me in the right direction if I'm troubleshooting something. 

It can also be what I would call a "projection tool." If you do daily or weekly or even monthly reports, it'll keep pretty good track of how much your bandwidth utilization goes up or down, allowing you to do predictive analysis via some of their reports. It's helped me know whenever I've had a circuit that was heading towards saturation.

The insight the solution provides as a result of its correlation of traffic flows and metadata is unique. It provides you with a unique perspective that I've only found with a couple of other tools. There are other tools out there that will do what Scrutinizer does. But what I have found with Scrutinizer is that it does it very quickly. I've taken 25 million individual data fragments from the different sensors, and it has graphed that and mapped it and presented a picture within 30 seconds. It has a very efficient database algorithm that I am really impressed with.

I do believe, if you ask the CEO of Plixer, that speed is one of their guiding milestones. They have a goal of being able to present data to the user, whenever it's requested, within 30 seconds or 60 seconds. In comparison to what I had previously, I could start a report, go to lunch for an hour or hour-and-a-half, come back, and it would still be grinding away on the database and not have generated the report. When I do that same type of analysis with Scrutinizer, I'm able to see that report within 30 seconds.

They're working on the security areas, so it can provide more insight. What they have is still pretty much IP-concentric. If they were to make it IP and URL, they'd be a little bit ahead on that. I'm not sure exactly where they're at on that topic.

I've been using Plixer for about three to four years.

It's one of the most stable platforms I've worked with.

The scalability comes from Plixer's ability to have different log collectors. You can separate the database collection point from the log collectors. You can also have different database points as well, and roll those up. That seems to be very scalable. Although, to be fair, I didn't have to scale mine up that much for 63 devices. I just have the one device which is also the log collector, so I was able to keep it all on one server.

We do not have plans to increase its usage. The majority of current usage, about 80 percent if not higher, is as a first-responder type of setup. If we have a problem, Scrutinizer is almost the first thing that we look at to determine what's going on, traffic-wise.

Whenever we call in for support, 99 out of 100 times, the first person we talk to can resolve our issue. They have an extremely good support team set up. Their folks are very knowledgeable. And that covers everything from troubleshooting a problem to actually doing upgrades. 

I have called in and said, "I really don't have the time right now, but I know I need to upgrade. Can I just give you access remotely and then let you upgrade it?" And they've done it for me. We're very happy with their support.

I work with a small credit union near Seattle, Washington. I found Plixer by checking and doing some blog searches and asking for recommendations from other network engineers.

Previously, we used SolarWinds' NetFlow Traffic Analyzer module. It did the job, but it was extremely slow. That was the primary reason we switched. So we looked around, and this was the best solution that we came up with, as far as bandwidth utilization goes.

The initial setup was fairly straightforward. I did engage their engineers during the setup to make sure that I was following their best practices. Overall, it's fairly straightforward, not only for the installs but for their updates which are very consistent as well. I don't even think updating takes it offline, except for whenever you have to do a reboot. You're online 24/7 and 365, unless you have to reboot for an update. And then it takes about 15 to 20 minutes to reboot it. It checks itself all over the place.

The full deployment took me about a week and that also involved the configuration and acquiring the sensors. Fixing up the base unit for Scrutinizer took a very short time. I did that in almost an afternoon, four hours or less. What did take some time — and if you do go with Scrutinizer, I will tell you to allocate the time — was that I had 60 devices that I had to go around and configure and get working. It took me a week to get it all dialed in, but that was just making sure that everything was recording correctly and working.

Our deployment plan was to first get the Scrutinizer base unit installed, up, and operating. We tested that by having one device report into it, a device that we were pretty familiar with what it was doing. Once we got that one base unit up and running, we configured the one device so that it was reporting JFlows, because we're using Juniper. Once we were satisfied that the unit was up and was accepting traffic and that we could do what we wanted, I had a total of 63 other devices that I went around to within my organization and pointed them at it.

We believe we have seen ROI with Plixer.

I said, "I need a tool." And they said, "Well, okay fine. One, tell us the cost. And two, tell us how long your projected return on investment is going to be." I found Plixer, and I said, "For the cost of what we're paying," at that time for SolarWinds, which was well over $20,000 a year, "this will do everything that we need it to do and will reduce our costs from what we currently have." 

There was an ROI calculation done on SolarWinds, but once their licensing exceeded $15,000, because it just kept going up and up, we were actually losing ground with them. That's one reason we replaced SolarWinds with the Scrutinizer.

They charge you by the number of sensors. The licensing model that they use, because it's on a number basis, means you don't have to have any cryptic SSL certs or anything else to install that are really difficult. For that part of it, the deployment and the installation, you have to make sure that server is right. Once it's up and running, you start pointing your devices towards it and there's no crypto that you have to decrypt or anything else. The licensing is all maintained through the number of sensors that are reporting into it.

Compared to some of the other tools we have, it's incredibly reasonably priced. The best part about that is that if you talk to their sales force, they'll give you a demo for either 30 or 60 days. In that 30 or 60 days, when we set the server it was for a couple of devices, just to test-harness it and see if it was going to do what we thought it was going to do. They'll let you see if you think you're going to be happy with it.

There are some additional modules that can be activated. I believe there's advanced reporting but I don't actually use some of their advanced features. There are additional modules that come with additional costs.

We did compare it against SolarWind's NTA and against another product as well.

SolarWinds was more of an all-things-to-all-people type of tool with a lot of different blades on the Swiss Army knife. Whereas Scrutinizer is pretty much one blade. I've got to be careful when I say that, because it still does a lot. But its main function is traffic analysis on the wire. And that's what makes it shine, because it does that one thing really well.

The biggest lesson I have learned from using Scrutinizer is don't be afraid to give the little guy a chance.

In terms of advice, every environment is different. You really need to kick the tires on it a little bit and try it before you buy. While it met my needs, and it met our environment very well, your mileage could vary on that. While I believe it to be a very solid, very good product, I would say: Put it in your environment and kick the tires on it a little bit.

When I did kick the tires, during that initial demo time, I wasn't able to get everything set up that I wanted to. They immediately gave me an additional 30 or 60 days. They're really good about that.

Plixer is a fairly young company, as far as Scrutinizer goes. That's usually a strike against somebody but, in their case, I think they went into it without any preconceived notions. Instead of being all things to everybody, they said, "Okay, we want to be able to do one thing really well," and they did it. That's what they specialize in. Although they could branch out and do all kinds of things with it, they're staying pretty true to what they originally planned to use the tool for. I'm going to be very surprised if they're not bought up by a bigger company which integrates Scrutinizer into its product as a module, because it's just that efficient.

It's its own little data silo. It's got a database in it. We've never really used it for eliminating data silos, although it certainly could be used for that.

I'm just now deploying an SD-WAN. When I saw that they were supporting that, I was ecstatic about it. I called them up to make sure that the SD-WAN we had chosen would be supported. In talking with them, they said they didn't have support yet for the particular brand that I had selected, but they were very interested in working with me, once I got it deployed and that they would support it. That was really nice.

Something that I hope they keep doing is maintaining the database efficiency that they get the speed from. It is just absolutely astounding how they can take data in and get those graph pictures, which they call "Plixers," painted. If they can keep doing that, and keep that efficient with all the changes that they make, they're going to be miles ahead in my book.

We have five different roles using it. My managers will look at it occasionally for reporting. My desktop folks will use it as a first-responder tool. My security manager will look at it to see if something has crossed our network that was never picked up. In my role, as a network engineer, I will use it the same way as the desktop people, as a first-responder. Finally, I haven't had anybody doing this until now, but I've got one which is going to be for cloud, for my developers to use. For maintenance of the solution, it's just me.

The primary use case was statistics. Now, it's mainly security and operations.

I am using the latest version.

It has become an essential and helpful tool for in my daily work. If we didn't have access to the tool, we would have more difficulty getting a long-term overview on the growth of our network. As we have gathered statistics for more than 10 years, we know about the implementation of traffic on our network to also justify our work and investments. From my point of view, it would be more difficult without a NetFlow accounting tool.

The solution helps enrich the data context of our network traffic. A very good example is a feature recently discovered denied firewall flows, which helps us understand what's going on in our DMZ. It also helps us figure out misconfigurations, It is really a very helpful feature.

It shows us the saturation of the network of devices. It gives us a clear view of the flows in the network to understand, for instance, planning upgrades in the network to get an idea of what's going on in the network for traffic flows. It gives us insight, for instance, on what's going on our VPN Client. There are a lot of things where it provides very helpful information. It also gives us our security reports with quite detailed information on what's going on in the network, and whether there are data exfiltrations and so on.

In a few cases, it has helped resolve network events. It has also helped resolve security events. We found a couple of security issues that we wouldn't have found without the tool.

• The automatic reports that we use for statistical purposes.
• The security analytics.
• The security alarms.

I have been using it for more than 10 years. My company has been using it longer.

On a scale from zero to 10, the stability is about an eight. From time to time, we have some issues that need to be fixed by their support. Usually, the support fixes the issues quite quickly. I would say it is between good and very good, in that range.

There is one person (the head of the network group) who maintains the server right now. There is also a backup if they are not available. We have a few people who are able to do some configurations on the system.

My personal impression right now is that we've reached a limit, or we are near a limit of flows per second, because we see that our system is getting quite slow. I suppose it's a hardware issue, not an issue of the software.

The actual size of the network is above 3000 users.

They are really great. With my most recent experience, two days ago, they responded quite quickly. They're immediately available. Usually, they have a solution to fix the issue during the call or web conference. With the most recent call, I had four questions and issues. They didn't say open four cases. They fixed or answered the four questions, then asked me whether I had other questions at the end. The support is perfect.

I never used another NetFlow accounting solution. I got to know the NetFlow concept at my current company.

The initial setup didn't seem to be that complicated. I found it already implemented, but we did a lot of migration steps. It seems to be quite easy to implement.

If I would have to implement it again, Scrutinizer is not that difficult to implement versus any other appliance. It is more complex to configure the exporters, but there is a lot of current, good documentation on the Plixer site for this.

In our situation with 25 exporters, it might take a half a week to do the implementation of the server. It's usually performed by Plixer, or with the help of Plixer and the hotline. First of all, I would use the test license to do a proof of concept to do the implementation. Then, I would test one or two devices, gathering some reports. I would also create an implementation plan.

We have seen ROI.

We recently bought a license upgrade, so we will integrate more exporters. We upgraded from a 25 exporter license to a 50 exporter license. Therefore, there will be more flows, and this will be an extension.

Compared to other solutions, the functionality Scrutinizer delivers is better.

I have one comparison to another product, which also has very basic NetFlow accounting.

When dimensioning the server hardware, we decided to have many CPUs, much memory and a large storage, but we learned that the storage has to be as fast as possible. It would have been better to invest in SSDs instead of HDDs.

We thought about using FlowPro. We see a very good use case for it, but right now we are working just with the flow collector for enhanced reporting.

It is really a very good security improvement. In the last two years, we learned that it's a very good security tool to learn more about what's going on in the network, not only in terms of network saturation, but mainly in terms of security incidents and break out.

Our primary use case is monitoring bandwidth and being able to go back and look at bandwidth issues.

We are on the latest version.

It helps us determine what is going on with our Internet and who is hogging it all up. If we get a real high throughput or a throughput that's going over and getting dropped fairly quickly, we can tell who (or what device) is consuming that traffic. That was our main use case for buying it to start with. Going forward, we will start using it for other stuff too.

We have only had it a couple of months, so we've not really dug into it a lot, but being able to know bandwidth is the main thing.

• Being able to monitor VPN user traffic has been nice. 
• Being able to monitor interfaces, in general. 
• We do a little bit of reporting, but we're just getting into that.

I wish the reporting side was easier to work with, but it does a decent job. I also wish the reporting side was a little more intuitive or they offered more reporting examples.

Their user videos could be a little better. They provided me a couple of training videos, but they were very generic in nature. E.g., if they had training videos specific to Cisco or Palo Alto firewall to give training to show you specifically within Scrutinizer what you could be looking at. They did provide a basic and an advanced training video. However, even the advanced training video doesn't break down into detail, and on the configuration side, that would be nice.

We've had it about two months.

I haven't had any stability issues with it at all. I haven't seen it flake out or experienced database issues.

I'm the only person who maintains and upgrades it.

It is easily scalable. I haven't seen any issues with it.

It is in full production. It monitors several firewalls, like Cisco Firepower, and IPS.

We only have three users who are using this solution as end users. We are all network administrators. It gives anybody within our group the ability to troubleshoot it easier.

The technical support was good.

We have Splunk, but Splunk doesn't give us the type of info that this does. Splunk is really clunky and hard to use. We still have Splunk, but we use it more as a security means for network means.

We have used the free version of PRTG, but that solution was clunky.

It was a pretty straightforward setup. I wouldn't call it complex.

The deployment took about four hours. We still expanding on it though.

I did the deployment.

We have seen ROI.

The solution has helped to reduce the time to resolution for network and/or security events by 50 percent.

There are no extra costs. It's about $8,000 a year. The bang for the buck (cost) is definitely a plus.

They gave us a 30-day license. We did a 30-day demo. We installed it, knowing that if we bought it, we could just add a license and continue on. So, we did a 30-day PoC, and they gave us good support during that time.

The solution has been around for a while. The monitoring of our firewalls was the driving concept for choosing it. They did well with demonstrating that ability.

We evaluated Cisco Stealthwatch, but it was so cost prohibitive that we did not go that route. It was about 10 times more expensive than Scrutinizer. Cisco Stealthwatch was very clunky and use. The menus were very different. While you could get a ton of information, you really had to dig to get it. There was some better features obviously, because the cost is a lot higher. It's more of a security network product, but it was hard to use and cost prohibitive. Also, we saw that its ongoing maintenance to keep it running would be a nightmare. There was a lot you had to do to keep it working correctly.

I would rate it an eight (out of 10).