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.
