vRealize Network Insight Reviews

The primary use is to identify different types of traffic that are in the network and identify what policies we need to apply to meet our security requirements.

The performance has been excellent.

It has definitely helped us to meet compliance rules by assuring that all traffic is going to where it's supposed to go. It can be used to report that you are in compliance, as well as helping you get into compliance. We use it on an ongoing basis to show our clients in our cloud that traffic is not going to them that isn't supposed to be. We have customers that have to be assured that our environment is safe for them, and it gives them that confidence, that knowledge. We retain customers longer.

It has reduced time to value for sure because it would be very hard to do this any other way. We would have to sniff packets, and that's just very labor intensive.

It allows you to see traffic that you couldn't otherwise see, which is traffic within your Layer 3-bounded network, meaning east-west traffic. It's hard to get that any other way.

To monitor the network flows, all you have to do is install it. It has an OVA that you deploy to vCenter, and then it will sit there, and it will listen on the network, and it will catch traffic within the virtual environment.

It is user-friendly. It's pretty simple to deploy and to run. It gives you pretty easy-to-understand reports, very graphically intense, so you can visualize what's going on in your network.

Reporting could be a little bit smoother. I would like it to be more intuitive to create a report that would automatically send stuff out on a periodic basis; for a management-oversight reports and the like. You can probably do that right now, I just haven't figured it out in the interface yet.

It's very stable. The way that it deploys and the way that it performs, it does exactly what it's supposed to do.

I don't know that I can speak to the issue of scalability, to a giant enterprise level, but we have quite a few servers in our farm, and virtual machines, and it has scaled well to that.

My experience with technical support has been very good. The amount of time it takes for them to get back to you truly depends on each incident. For me, it wasn't an emergency situation, so it took a couple of days. But if we do have a situation where something is down, then they get back to us immediately.

In term of customer service, we are a VMware partner, so we get different customer service than other people do, but ours is very good.

There wasn't really anything similar to this before. We knew that there were things going on, but we really couldn't tell. We didn't know how to get at it and, when we found this solution, it was a no-brainer that we were going to try it. They give you a trial version on it so you can see if it's going to be of value to you before you purchase it. It showed its value right away. This solution came to us. We weren't actively searching for it at that particular time.

The most important criteria when selecting a vendor, for us, are that 

• we know the vendor has been around
• we have confidence in them
• they have a good support system.

We are always going to have issues with products, so if they can help us overcome those issues, then we're much happier with the product.

The initial setup is very straightforward. It's set-it-and-forget-it.

Cost always has room for improvement, you could always make it cheaper. But I think it's a good value for what you pay for it.

The primary use case is for tracking flows within the data center and it has worked very well.

It has given us much better insight into how we're deploying and how we perform after we deploy. It has also definitely helped to reduce time to value, and definitely helped provide deep visibility.

We tend to rely on vROps for the monitoring aspect, the performance piece of it, but that's because we're particularly focused on capacity right now. I expect to run the two in parallel when we're in a more operational model, where I will have the day-to-day folks deeply involved. Right now, it's still primarily run by engineers.

What's valuable to us is the ability to get a view into the virtual space, which is something we haven't had before. Before, it was done by collecting from network endpoints and extrapolating into the virtual environment. Now it's coming directly from the virtual environment.

It's intuitive and user-friendly. It makes perfect sense to somebody familiar with the VMware world.

In a very general way, I would like to see an improvement in interoperability with third-party product, from other vendors.

We've had no issues at all with stability. It has been solid.

Scalability is still untested by us.

The team has used technical support, although I am not familiar with the outcomes. We've generally been happy with VMware support across the board, so I can't imagine the experience has been different for this product.

We came to the conclusion that we needed to invest in a new solution by working with the VMware team. It was not an impulsive decision by any means.

The best ROI is "sane deployments." It's not intuitive, but it has actually helped us keep the number of deployments down, and we definitely get placement right the first time much more often.

If you're VMware shop, investigate this deeply because it makes sense to live in the ecosystem.

They have a legacy environment that they're trying to use microsegnmentation on. So the use case is to facilitate that because they don't necessarily know a lot of the firewall rules from the original environment, which was a physical environment. Now that it has gone virtual, they want to use the vRNI to get better firewall rules in there and make it more streamlined.

The main usage of it is microsegmentation and troubleshooting, not real monitoring of the environment, because we have other tools that do the monitoring of the environment. But when it comes down to bringing in new environments and making sure they're microsegmented, it's pretty easy to use for that purpose. No other product is available to do that.

And we use it for troubleshooting because it allows us to go from virtual through NSX, up to the core, and see all of that in one pane of glass. It's pretty easy.

Right now, since the PoC, in the environment that we're using it on, for troubleshooting any issues that come up, or in the case of the microsegmentation, it's very valuable because it has allowed us to add firewall rules that were specific to what we needed, and not the extra firewall rules that other people thought we needed.

It has allowed us to easily take the physical environment and bring it into virtual and then put together the firewall rules that were needed, not necessarily firewall rules that everybody thought we needed, which were already in the old firewalls. We were able to do that much quicker doing it this way, rather than trying to weed out all the rules that didn't necessarily need to be there.

Troubleshooting-wise, we did have a problem in the environment and it made it easier to find the actual issue, the real issue, not something that we thought was the issue.

The microsegmentation is valuable, especially for this environment.

Also, the ability to troubleshoot all the way across the NSX part of it to the physical and actually watch the packets go through and then see where the bottleneck is or where the interruption is, is valuable. We run queries on the network flows within the application to find where they are in it and it graphically tells us how the packets are actually going through the system.

It's very user-friendly in the sense that the querying is just regular language like you and I speak or write. You don't need to know any SQL-query type of language to be able to get what you want out of it.

The only real improvement they can make is to add more third-party vendors into the environment, mostly switch manufacturers, because it's really limited to Cisco equipment and there are a lot of companies out there other than Cisco.

It seems to be very stable. I don't know how it's going to be when we go into production. Right now, we have a single instance of it, but in production, it has to be a cluster environment and we haven't really tested that part of it.

When it goes into production, it's going to have to scale from this one, small installation to a much larger installation for our purpose. It seems like it will do it pretty easily, but we won't know until we actually do it.

It was pretty easy to install and the documentation for laying it out seems to be easy to follow, design-wise. It was very straightforward.

We've upgraded four times with it and the upgrading was pretty easy as well.

It could be cheaper, of course.

We're not really comparing it to any other vendors. I don't know of anyone that does microsegmentation and whose solution is integrated within VMware's environment

It's a pretty good system if you're doing troubleshooting and microsegmentation. As a troubleshooting tool, it's a level-3 troubleshooting-skills tool and it's very easy to use and very easy to find the information that you need.

I rate it a seven out of ten, only because it doesn't have all the vendors - at least the switch vendors - in there. They only have Cisco, for the most part, and you really need all of them to make it because companies don't just use Cisco for everything.

vRNI taught us to troubleshoot issues and help us implement our NSX product. Therefore, it's been one of the most valuable tools of the product.

We're in a huge NSX implementation right now and trying to understand each application. vRNI's been very helpful in helping us protect each one of those applications.

They are already working on it, which is really nice. It would be the capability of actually identifying certain applications, like SQL, file servers, DNS, AD servers, and making it easier to identify those types of systems.

Stability for vRNI - it just works. We haven't had any issues with it.

The scalability is great. We haven't had any issues with the capability of the machines, NSX, or with the implementations of both.

Personally, I have not called technical support.

I was not involved in the initial setup.

We had an inner engagement, and their engineers highly recommended using the tool, as far as the implementation for NSX.

Before this, we weren't using another solution at all. We're pretty much using VMware for this type of environment.

Support is very important, to be available especially for issues that may be new with the features which we're trying to implement. We tend to request support quite a bit, so support is definitely very important.

I would definitely advise, especially healthcare companies that need to secure their products, NSX using vRNI as their tool. To implement it, I would highly recommend that they invest the time to learn how to use vRNI.

It's mainly for monitoring so that we can design our NSX firewalls.

Previously, we had no idea how the dataflow worked. We knew how all the applications and servers worked, but we never knew how the dataflow was happening. vRNI provides more insight into the dataflow.

It definitely saves times because we are not using this for performance monitoring and not really for monitoring for troubleshooting.

Dataflow. We tag our virtual machines and then we try to find out the traffic between the web server and app servers, and the traffic between the Dev servers and Prod servers, so that we can build the firewalls around them.

We just started using it so I don't really know a lot of the features yet.

The stability is good. It has never crashed.

I haven't tried to scale it yet.

We had the VMware Professional Services team when we started with our NSX project. They helped us set this up and familiarized us with how to use it. They were helfpul.

If you have a VMware suite and you are going to use NSX, then I would definitely recommend vRNI.

I rate the solution at eight out of ten. I'm still getting familiar with it. The UI, even though once you get to know it, it's easier, still it's hard to figure out by yourself. You have to go read, watch videos. It has a lot of data on it. So that is an issue.

Like most companies, we don't necessarily know what ports are necessary for our applications to talk to each other, so we're hoping to get insight on that for increasing our microsegmentation with NSX.

In terms of monitoring network flows, we're just looking specifically at the flows within one VDS, so we can dive down through that VDS and isolate virtual machines. Then it gives us that visualization. We have not moved into the physical side of that at this time.

It's performing very well. We're still going through the learning pains so we haven't quite got out of it most of what we're looking for, yet. We understand that it is in there, we just don't understand how to get it yet.

We're only at the evaluation stage but the benefit we're looking for is to speed the production deployment of the applications in a microsegment environment. We would love to get to that ring of Zero Trust but we're just not there today.

The most valuable features for us are the visualization of the applications. We can actually take them and expose them to our applications analysts as well because they want to know, it's just that they're not necessarily exposed to ports. As somebody told me the other day, "A port is something you plug a cable into."

The solution is also extremely intuitive and user-friendly. When you log in to the application you are presented with a dashboard that is very reasonable for an initial user, and you can then customize it to your specific needs. But for all the data that we've found, we've only had to go through two or three drill-downs to get into that information. So far, we haven't found anything that is very misleading. Sometimes you'll get into some misleading things, "Oh, this is not where I wanted to be," but we really have not found that with the product.

One of the things I've asked about is regarding Log Insight, with their syslog collector. There seems to be a lot of overlap between that and vRNI. I've asked if one of those is going away or if they're moving together and I really haven't been able to get a clear answer. I would like to know that.

It's been very stable. We have not had any problems at all with the deployment.

We haven't made it to the point where we're scaling yet. We haven't hit any performance issues that would cause us to evaluate the scalability.

Technical support is very responsive, knowledgeable, and they're quick to get things done.

We didn't have anything in this space on the virtual side. As we moved deeper into the virtualized world, we lost some of those traditional physical network visibility tools. We were using some of the native NSX visibility tools incorrectly and causing NSX problems, trying to expose that information to our analysts. This was the solution that they gave us that would fix that. I think AppDefense now adds some of that back, but hopefully, they'll work together.

The most important criteria when we're looking at a vendor are

• reliability
• usability.
  

We initially went with what we were using on our traditional memory side, your traditional network monitoring. CA Spectrum is what we use on that side. We've looked at that and some basic netflow monitors.

We would absolutely recommend it. In fact, we've had that experience where it was recommended to us and we said, "We need this, we need to do this."

We are very positive so far with everything we've seen in this tool.

We use it to manage our servers, our virtual vSphere environment. It has performed exceptionally. We're able to get a lot of versatility into our network, into our STDC, with the VMs and the NSX that we also have running.

It has really tightened down the security. That was something that we were lacking.

It has also given us deep visibility into our network. We can really get down and see all of the traffic within the data center, between the VMs, between the applications, database servers, other application servers, web servers. We can identify everything that is communicating, and we can see it all on one product.

The most valuable feature is the visibility into what's going on, our traffic going through the data center. We'd like to put in micro-segmentation, eventually, so that we can actually protect our data center, our VMs, within the environment. It would just add another level of security. It gives us the visibility to do that.

I find it user-friendly and intuitive. With the GUI interface that we do use on a regular basis, it's easy to navigate, it's easy to see, easy to query. We get reports. It's easy to use.

I'm not quite sure what features I would like to see in a future release. We haven't explored everything in the product yet. We're able to pull out of it what we need right now.

We haven't had any problems with stability. We pretty much implemented it with a brand new solution - we implemented it at the same time as a data center refresh we just went through. We're really looking to be able to take it to the next level and put some micro-segmentation into our data center and this tool will help us do that.

Scalability has not been an issue at all. Since it's a brand new build, I'm not quite sure yet because we haven't had the need to add additional servers or additional VMs. But I don't anticipate any challenges there.

The technical support has been great. We have vendor support as well as technical support with VMware. We really haven't run into too many challenges with this product at all so I can't say that I've even had to call tech support yet on it. It has been running pretty flawlessly.

We had a previous version of the hardware - I'm not going to say who the vendor was - but we had a previous hardware implementation that had to be pulled out and then we had to bring in a newer version of it because it did not meet our needs.

We went with this solution because I was working with that vendor when they actually made good on the deal and made it more attractive for us to stay with their solution instead of going to bid again.

The most important criterion when selecting a vendor is the ease of working with them. Honesty, communication, obviously. We want them to let us know if there are any pitfalls, anything to give us a heads-up on, we'd like to hear that. We've had some problems in the past with some vendors that didn't disclose everything and that caused some challenges. We are definitely looking to work with vendors that are trustworthy.

The initial setup was very straightforward. A big reason why we come to these shows, like VMworld 2018, is to get some more knowledge and training and talk with the professionals. We worked with VMware on the setup, and with our network engineer and our sysadmins. With their help, it was pretty easy to implement, no challenges there.

I would rate it an eight out of 10. It's not a 10 because of our experience with the vendor. I believe the product is a great product and, obviously, the VMware applications that we're using, we have had no issues with them.

Our primary use case for vRNI is to have an overall dashboard for east-west traffic in our hospital. It is used to catch anomalies, like system which are not being used or being overutilized. Its performance is great.

vRNI has improved our organization mostly through our NSX deployment. When we deployed NSX, we were able to watch the flows and create the rules which are normally unseen. When we are going through an application, we have a list of ports (allow or denied rules in NSX). With vRNI, we are able to watch what is happening. If something is not listed or spec'd out by the vendor, but still necessary, like interfaces or engines, we can catch them without causing downtime to the production application when we implemented NSX.

It definitely helps us manage our network. It provides that deep visibility into what is happening with traffic. You usually don't think of where your traffic is coming from (e.g., this server is connect to that server), but you have your authentication level and other flows that you never even think of. This product helps us with the visualization.

The most valuable features of the vRNI is to be able to catch anomalies as they pop up. 

If we have a question about how something is being used, or not being used, we can go to vRNI, review it, finding systems that should have been decommissioned. They are just sitting there as unclaimed resources. 

vRNI is extremely user-friendly. Out-of-the-box, we can hook it up to our vCenter and our Cisco switches too. It will pull on the flows and immediately, within the first ten minutes, you can see the traffic. It is very intuitive. It will find the normal flows as it records the traffic. It is a very nice product.

vRNI needs more remediation where it hooks into NSX. This was just brought up at the keynote speech.

We are totally stable. Out-of-the-box, it starts running day one. We have not had an issue so far.

As far as scalability, give vRNI disk space and it scales out.

We have not used tech support with vRNI so far. 

I was involved in the initial installation. It was very straightforward and simple: Give it an OVA and IP address and point to the vCenter and switches. 

We have not gone through an upgrade process yet, but I don't think it will be an issue. We will see when we get there.

Our NSX team helped us do the install in the beginning. So far, we haven't had any questions about it since the initial installation.

The solution has reduced the time that we spend on other products. For example, with NSX, we were able to quickly find things that we would normally spend days trying to figure out.

We never even a solution existed until we saw vRNI.

I would rate the vRNI a ten out of ten. It has given us value since day one. We can see more than before. This helps.