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.
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.
Network Manager at a energy/utilities company with 5,001-10,000 employees
Real User
2019-12-12T07:48:00Z
Dec 12, 2019
The primary use case is to analyze the flow found within the network. It helps us understand how the network is used, e.g., if it is mainly used for email or private application. It is very difficult to use functionality and provide features to understand how in the future the network will be used because the application is growing and developing so fast. So, the data flow could be exponential. That's why it's a daily challenge to understand how the network is in use and how we can manage to renegotiate the contract to improve the bandwidth, but it has very good tools concerning the network and network analysis. It has helped us a lot with troubleshooting. I am using the latest version.
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.
Business Security Officer at a insurance company with 1,001-5,000 employees
Real User
2019-11-13T05:29:00Z
Nov 13, 2019
Our primary use is troubleshooting. Our secondary use is capacity planning, investigations, and reporting. We use it with multiple vendors sending flows to us.
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.
The Scrutinizer incident response system leverages network traffic analytics to provide active monitoring, visualization, and reporting of network and security incidents. The system quickly delivers the rich forensic data needed by IT professionals to support fast and efficient incident response.
My company's clients use Plixer Scrutinizer for network monitoring elements, like CPE, and for a bit of network inventory management.
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.
I use Plixer Scrutinizer for Network traffic analysis.
We used this solution for MTA. I am responsible for the network; I would have been the only person using this solution.
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's a NetFlow collector.
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.
The primary use case is to analyze the flow found within the network. It helps us understand how the network is used, e.g., if it is mainly used for email or private application. It is very difficult to use functionality and provide features to understand how in the future the network will be used because the application is growing and developing so fast. So, the data flow could be exponential. That's why it's a daily challenge to understand how the network is in use and how we can manage to renegotiate the contract to improve the bandwidth, but it has very good tools concerning the network and network analysis. It has helped us a lot with troubleshooting. I am using the latest version.
The primary use case was statistics. Now, it's mainly security and operations. I am using the latest version.
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.
We mostly use it to monitor the network bandwidth utilization on various links.
Our primary use is troubleshooting. Our secondary use is capacity planning, investigations, and reporting. We use it with multiple vendors sending flows to us.
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.
The primary use case is to track utilization flows for security and for scalability. We use it to see network usage.