Using vRealize Network Insight with VMware Cloud on AWS

Last updated on 7th January 2021 with vRNI-HCX Fling link

This post will walk through how to use vRealize Network Insight with VMware Cloud on AWS.

Recap on vRealize Network Insight

I’ve been a fan of vRealize Network Insight (vRNI) ever since the days it was still called Arkin Net.

When I first started using it over 4 years ago, its primary purpose was to help customers operationalize NSX.

It’s a simple tool you can easily deploy it (two OVAs deployed in under half an hour – it’s very simple), connect it to a vCenter (vCenter would be a vRNI Data Source), analyze the traffic to and from virtual machines and build NSX security rules in a matter of a few clicks.

Traffic flow information is based on IPFIX. Here is a brief description on IPFIX I wrote in the VMware Cloud on AWS Network Book:

Internet Protocol Flow Information Export (IPFIX) and its predecessor NetFlow are used by network and security administrators for troubleshooting and auditing. In the past, many network operators have relied on Cisco’s proprietary NetFlow technology for traffic flow information export. NetFlow is the basis for IPFIX, which is a modern IETF-standard protocol for exporting traffic flow information.

A flow is defined as a set of packets transmitted in a specific time slot that share the same 5-tuple values: source IP address, source port, destination IP address, destination port, and protocol. The flow information may include properties such as timestamps, packets/bytes count, input/output interfaces, TCP flags, or encapsulated flow information.

An IPFIX architecture requires identification of exporters – network entities that observe the traffic leaving/entering and export the traffic flow in the IPFIX model – and collectors – systems that receive the flow data.

Table 1 shows typical information in an IPFIX packet.

In summary, you could easily inspect the traffic flows from your virtual machines and based on the traffic observed, vRNI would automatically recommend security rules.

---

We’re up to vRNI 5.2 now and the product supports many different types of data sources beyond just vCenter:

• VeloCloud SD-WAN
• Kubernetes
• Multiple native public clouds and of course,
• VMware Cloud on AWS.

It’s also available as a software you install in your DC or as-a-service (vRNI Cloud).

Recap of the recap: vRNI provides visibility into your infrastructure by analysing data (mostly traffic flows) from your various data sources and providing insight through analysis.

This post will go through a number of interesting use cases of vRNI (also known as ‘vernie’) with VMware Cloud on AWS:

Visibility of Hybrid Applications

One of the killer use cases for VMware Cloud on AWS is integrating with the native AWS services. I have blogged at length throughout the blog. One use case is to leverage the native AWS Elastic Load Balancer (ELB) to load-balance traffic between workloads. This blog post describes this at length. In a nutshell, we have an ELB in native AWS load-balancing traffic between three VMC Web servers.

While this is a great use case, troubleshooting can be tricky as it’s hard to visualize traffic and network flows when it crosses native AWS and VMware Cloud on AWS…

That’s when vRNI comes along. vRNI supports VMware traffic flows but also AWS traffic flows – referred to as VPC Flow Logs – and can aggregate them together. In the picture below, I set up VPC Flow Logs in my VPC and all Flow Logs are exporting to vRNI.

Friendly remember: VPC Flow Logs are not free, although not particularly cheap: it’s $0.25 per GB for the first 10TB and it would appear on your AWS bill, not your VMware Cloud on AWS bill.

It’s straight-forward to add an AWS account to vRNI as a data source using an AWS Access Key and in minutes, you will be up and running:

By pulling traffic flow data from my AWS account and from my VMware Cloud on AWS SDDC, I can see traffic coming in from the Internet and hitting the AWS Elastic Load Balancer and been distributed across the three ‘real’ virtual servers.

Migrating Applications

Martijn did a fantastic job explaining how you can leverage vRNI to plan your migration to VMware Cloud on AWS in a couple of posts: this one and that one. I recommend you read both posts.

In essence, what customers are asking when they are migrating some VMs / a cluster / an entire datacenter to VMC on AWS is: how do I understand the dependencies between my applications? how do I understand which VMs should be migrated together? Martijn describes how to build ‘migration waves’. A migration wave is a group of VMs that would be migrated together, typically by HCX.

You can now automatically take the applications created from vRNI directly into HCX. Read this post for more details.

Some customers might want to group them by vSphere tags. This is what I do in the video below: I group all VMs based on the same tags together.

Once all the workloads have been grouped together, you can analyse the network flows and see if most flows are within the group or if they have dependencies with another tier/app/group of workloads.

You can build the groups of applications using tags as describe above, using a naming convention (assuming you have one!) or you can leverage “Flow-based” discovery: a new feature, which is (as I type this), only available in the Cloud version of vRNI.

The benefit of flow-based discovery is that the user does not need to input anything: vRNI will automatically group VMs together based on flows and apply some “ML Magic” (yes, the term is partially used tongue-in-cheek) to group them together. In the brief video below, vRNI Cloud automatically grouped my VMs with dependencies into separate groups: I’ve got groups for Tanzu Kubernetes Grid, AVI Load Balancing, etc…

Egress Traffic Charges Calculation

This is a common concern and objection I get from customers: “moving to the Cloud will cost me too much in terms of egress data charges”. Most (if not all) Cloud vendors do not charge for data entering the Cloud but charge for data leaving the Cloud (also referred to as “egress data charges”) and obviously VMC on AWS will follow the AWS model. The price per GB depends on the region and whether it goes over Direct Connect or Internet but it’s typically:

	Price
Internet	$0.05 per GB
Direct Connect	$0.02 per GB

I had a customer who told me they anticipated egress charges would be too high to make VMC financially viable. To determine it, we installed vRealize Network Insight and looked at the total traffic over a day and we then extrapolated:

If you look at the example above, you can see that Internet/North-South traffic is roughly 500 MB. If you were to lift the entire VMware estate to VMware Cloud on AWS, East-West traffic in this case would be free of charge (East-West is internal traffic essentially).

500MB * 365 * $0.05/GB = $9 for the annual traffic cost. While this example is for a small test lab, I have run this type of assessment for many customers and even for very large estates, I haven’t seen egress data so high that it would have a major impact on a customer’s bill.

My colleagues Ed and Robert actually wrote a blog post on this a couple of years ago. We also now have the ability within vRNI to see the “egress data charges” on the vRNI VMC dashboard:

Now, in this particular scenario, all traffic to the Internet actually goes over the Direct Connect (re-read the Internet Design Guide for VMC if necessary) so for this customer, the charge would be (if we extrapolate the data from a day to 365 days) :

410MB * 365 * $0.02 per GB = $3 per year.

Traceroute on Steroids

vRNI gives you some cool visibility on networking connectivity: I really wish I had a tool like this when I was a network engineer.

For VMware Cloud on AWS, it can show you the traffic from a VM to a VM in the same SDDC:

It would also show you the path the traffic would take to reach the Internet from a VM.

The traffic from the VM goes through the Distributed Firewall (click on the little Firewall to see the FW rules applicable to that VM)….

And then across the T1/T0 routers before heading out to the Internet. Click on the Firewall next to T0 to see the ‘edge firewall’ rules applicable to this traffic:

Finally, we also have something new that came up with the latest release of vRNI 5.2: the integration with Direct Connect – we can now see on the vRNI Dashboard details about the DX used (such as the Direct Connect ID and the Virtual Interface (VIF)) and the routes learned and advertised over BGP:

Even better, you can see the traffic from a VM on VMC accessing a VM on-prem like in the picture below. You need the ability to add the DX customer router as a data source to see this path – I didn’t have the ability to do this in my lab so I borrowed this picture from Martijn.

Microsegmentation

Going back to the original purpose of vRNI and its ability to analyse traffic flows, that works perfectly well here as well. Deploy vRNI and it will collect network flows. It will automatically recommend rules that you can implement on your VMC Distributed Firewall:

I hope you found this useful. Thank for reading.