What is your primary use case for vRealize Network Insight?

With vRealize Network Insight, I handle virtual virtualization products, particularly with VMware, focusing on Hypervisor and VSAN. I deal mostly with governments, agencies, and medium to large enterprises.

We are using vRealize Network Insight to map all the connections between the servers.

We have deployed vRealize Network Insight in two or three environments for our customers' NSX implementations. It helps us in creating the network architecture and planning before deploying NSX. We use Network Insight to gather data and determine firewall rules and communication between virtual machines. So far, vRealize Network Insight is helping us to decide on architecture and NSX networks for our customers.

I use the solution for virtualization and monitoring purposes.

I'm a consultant. I'm consulting and setting it up for my clients. I don't have one running in my environment. Its use cases include: * Deeper analytical insights into network traffic. * Ability to troubleshoot network performance issues within the environment. * NSXT, micro-segmentation recommendations after a thirty to sixty-day learning period to remove redundant firewall rules, make more efficient firewall rules, and then bring down the individual limits, i.e, the limits on how many firewall rules you can have on a vNIC. I also like them to use it for dependency mappings as part of migration projects and figure out everything is talking to what and ensure that we have them all in a consistency group replicating consistently. When we fail them over, bring them up in the proper order they need to be brought up in. Those are just a few of these cases.

We use the solution for NSX-T Manager and the customer wanted to have the firewall rules in order to achieve micro-segmentation. To analyze their environment, we use vRealize Network Insight which provides us with all the firewall rules for traffic to and from. This is why we use vRealize Network Insight.

vRealize is used to help our development team by producing detailed reports of the network flow and layout. This includes details like the TCP network keys and the RTT.

From the time that it was available, we've been using it for various reasons and it's been proven quite successful in our virtual portfolio products, especially in the VMware environment. While we don't use the solution per se, we do sell it to clients and offer support. It's normally deployed in the virtual blinds mode, within our customer base. Then we take that as part of one of two of the things we do. We use it as a baseline and an assessment enabler to enable the assessment around the network typology. Users get a lot of value. They can see which application is talking to which application through which virtual machine, through which virtual switches, et cetera. Then users can take that information and meet with the client or their team and then remediate the environment so that it is more optimal. The best traffic routes and flow can be found and optimized. That's two of the typical use cases. One is for assessment and one is for optimization. Thirdly, users can operationalize their teams or customers so that they can use it themselves going forward.

At IBM we enable vRealize Network Insight in our mission-critical architecture, so we'll be using vRealize Network Insight to monitor and get deep inside to our networking, including with NSX.

The primary scope of vRealize Network Insight is deployment of NSX to visualize north-south and east-west traffic. We mainly use it to implement data on the NSX.

I use it to monitor and log the traffic for our virtual servers. We are migrating our virtual servers into a new software-defined data center from a legacy infrastructure. When I migrate the reports into the new infrastructure, I use vRealize Network Insight to monitor or log the traffic from the servers and implement those reports into the NSX firewall. Therefore, our servers will be ready for our migration into our new data center.

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.

For this product, we wanted to introduce NSX into our environment. Previously, we were using all Cisco, so we wanted to try Network Insight to find the vulnerabilities in our environment and whether our environment was compatible with NSX. That was the premier objective in using this product.

Our primary use case for the product is for preparing for NSX deployments, looking at flows between VMs, and to help us troubleshoot also.

We use it for networking and it has performed well.

The use case is to get insight into the network, how many resources are being used. We look at the GUI and see what kind of traffic flows are happening east-west, and who is talking to whom, and how much bandwidth is consumed. That can even give us some idea about capacity planning.

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

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.

We want to use it for the basics, checking out traffic flows. One of the main reasons we got it was that we have a new mobile application, and we'd like to track all the traffic between the different layers: DMZ layer, database layer, app layer.

We mostly use it for profiling applications. It works quite well.

Our primary use case for the solution is to monitor the end-to-end network aspect of our environment. The performance is really good. We don't have any delays or the like. It gives us really good performance.

It's not just on the networking side that we use it. We use vRealize products in our product data, in developing software, as a managed cloud provider. We use vRealize Network Insight as part of our product, which can later be used by the support team to check all the problems which are arising in the network itself. We use software-defined networking, SDN. That's one reason we are using it. In terms of its performance, we are still in a beta version of our product itself. We are not using it greatly in production yet but we will be using it in two or three months, down the line. There are network flows that we need to know about, if there are any anomalies in the network itself - depending upon the network that our team has deployed. That's the reason we use the vRNI tool, to look into all these parameters. We also use it for a few performance parameters, depending upon if there are any configuration issues in the network that we have deployed. vRNI has given us a few recommendations on how we can actually set up our firewalls.

We actually write a plugin for vRA that allows customers to integrate with third-party vendors, such as IPAM solutions, DNS, SolarWinds, BlueCat, Infoblox, and about 30 other modules. We both use vRNI and build for it. It has been performing really well.

We use it to monitor the network, the infrastructure. It's performing well.

We use it to capture the logs from the network and then build and figure out the policies for microsegmentation. In addition, if anything goes down, it captures the logs. We have it integrated with vCenter and NSX Manager. It captures the logs from there, and then it updates the logs. From there we can figure things out. Also, we can make a bubble and then we can figure out the grouping.

We use it for auditing our firewall compliance. For network segmentation, we want to see that we are compliant and that we are staying compliant with the business goals. We've been using it for about six months and the early work we've been doing with it is promising, it looks good.

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.

We are attempting to discover legacy network transactions and convert them to micro-segmentation rules with NSX-T.

For us, it's for a security tool, to analyze flows and network traffic and to try to progress along the path of microsegmentation. In terms of monitoring network flows, if we're trying to set up microsegmentation rules in our distributed firewall, we'll say, "Okay, let's just start with a case." We'll try to isolate an app, and isolate all the network traffic there. We'll analyze it, validate or do discovery using vRNI, and then set up the appropriate rule.

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.

We currently use it to find specific defects in our network flows. We're trying to streamline all our virtual needs with respect to network flows. The primary use case is to make sure that we disperse our dollars in the right sense; that we use it the way we're supposed to use it, optimally. The idea is to understand how it works and do more of it and eliminate things that don't make sense. In terms of performance, so far so good. Nobody is complaining.

Our primary use case is to use it do design and for troubleshooting the future. We have had the product for three weeks now.

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.

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

We use it for network troubleshooting, to provide some capacity reports, and to help generate rules for NSX microsegmentation.

We used it for our VDI solution to track down all of the network beginning and endpoints.

We're using it for our microsegmentation project. The performance has been good.

We are able to analyze application flows through the network. It is performing very well. It allows us to do a quick analysis of protocols, applications, and network pathing for our customers, then it has them analyze their needs for working application availability.