vRealize Network Insight and Visibility in the SDDC

Single Pane of Glass Visibility

How many times have we heard the phrase "single pane of glass"? It seems like we are getting closer to that saying becoming true, at least from gaining valuable insights to what types of traffic are crossing our environment. VMware's vRNI allows customers to have a self-learning, self-populating and automated method for determining what security policies should be put in place. This is true for east-west traffic (VM to VM) as well as north-south traffic, essentially providing 360-degree visibility across virtual and physical networks. This is especially important when planning for security implantation for micro-segmentation deployments using NSX, as it allows the customer to truly see what types of flows applications are using to communicate.

Basics for Getting Useful Information

For vRNI to bring back results that are useful to the company, it needs to run for a little while. Typically speaking, the longer we can let it run, the better the insights are. This includes vRNI finding patterns in the ephemeral ports that applications use for their source ports, finding outliers and many other useful features that traditionally would consume a large amount of human effort and time to drill down and find manually. We also need to identify the data sources from which vRNI will learn from. These can be virtual appliances such as NSX or VM's, physical hardware devices such as a network switch, a physical firewall, and support for visibility into Amazon AWS.

Troubleshooting Value from vRNI

vRNI is also a very valuable troubleshooting tool, allowing administrators and engineers to drill down deep into the packet flows and view what processes or properties may be applied to those specific flows. For example, it could identify what security groups a VM may belong to, what firewall policies will it be processed against, what subnet does it reside on, what resources are being consumed, and many more telemetry elements.

vRNI can show us how traffic flows through the environment as you can see in figure 1.

Figure 1: Traffic Flow with VRNI

We are able to see a view of the topology (figure 1) and a path view. This gives us a visual representation of how traffic is traversing our SDDC. In a troubleshooting scenario, we could see where packets are dropped; for example, a new security rule has just been added on the firewall that may have been placed out of order or may have been entered incorrectly. vRNI will show us the path the packet took, where the packet stops and the specific firewall rule that was hit that caused the packet to be dropped. At that time, we can easily go move the firewall rule up or down in the processing order, or adjust the rule as required.

Simplifying Deployment of Micro-Segmentation Security Policies

When we talk about applying security policies, we can allow vRNI to make recommendations based on the specific communication patterns and traffic flows that are required for the applications to work properly, convert the recommendations into a CSV file or XML, and then import that into our firewall. This helps to eliminate a tremendous amount of time and unnecessary guesswork to get the network to a fully locked down state where only the required traffic is permitted across the SDDC. This is especially useful when application owners may not know exactly how every part of their application communicates. Below are some of the basic steps to get that process started.

First, we would click on "plan security" as shown in figure 2 below.

Figure 2: vRNI Security planning

Next, we will choose an "entity" to plan for, and from what time period we want to see the recommendations from. See figure 3 below.

Figure 3: vRNI Security planning options 1

Notice when we click on the "Entity" drop-down box, we have many options to choose from, as shown in figure 4 below.

Figure 4: vRNI Security planning options 2

If we select "by Applications" from the drop-down box, then it shows us the different application flows vRNI has captured, what talks to what, if it is an incoming flow, outgoing flow or a bidirectional flow. Shown in figure 5 and 6 below.

Figure 6: vRNI Micro-Segments 1

Figure 6: vRNI Micro-Segments 2

For this example, we will focus on the CRM application. If you click inside the wheel on CRM, we will be able to drill down into the flows for that specific application.

Below we see there are 12 services in this group, 5 external services being accessed and 4 recommendations that vRNI has made for firewall rules. It shows us which ports the CRM application is using and the recommended action - in this case, to "allow" the four types of traffic listed below in Figure 7.

Figure 7: vRNI Service and Flows

From there we can export the recommendations in a CSV or XML format and then import into our firewall as shown in figure 8 below.

Figure 8: vRNI Service and Flows

As you can see, with just a few clicks we were able to gather tremendously valuable information about traffic flows from a specific application (CRM in this case), get recommendations from vRNI for firewall rules, and export those rules so they can be imported on our firewall(s).