Introducing the NTA 2020.2 GA Release - VMware vSphere Distributed Switch support
Welcome to our latest iteration of the NetFlow Traffic Analyzer, available now in yourcustomer portal
Version 2020.2 is the next release following NTA 2019.4 and is compatible with Orion Platform 2020.2
This is one of three articles describing features we're introducing in the NTA 2020.2 GA Release. We’ll post the details of these features in three separate discussion threads in the NTA product forum, to help you focus on the problems you need to solve in your environment.
In this first article, we’ll discuss our comprehensive support for the VMware® vSphere Distributed Switch (VDS), providing visibility within the switch fabric to your east-west VM traffic.
Release notes and system requirements for NTA 2020.2 and related Orion releases can be found on this release summary.
VMware VDS Support
Traffic visibility within our data center switching fabric is notoriously difficult to acquire, but critically important to understanding how our workloads relate to each other and communicate. Support for the VDS helps you to understand the migration or placement of workloads in terms of the traffic they generate with other machines, or dependencies on external network services.
VMware’s Virtual Distributed Switch extends a switching fabric across multiple hypervisors in a data center, and can be configured to export IPFIX flow records.
In the latest release of NTA, we discover the membership of the switch fabric through the vCenter interface, and then receive and display endpoint to endpoint traffic that’s sourced from the hypervisors. Optionally, the switch can be configured to source all IPFIX records from a single IP address assigned to the VDS, but in most cases it will be more useful to see traffic instrumentation sourced each hypervisor. The traffic records we receive will represent conversations to or from the VMs on those hypervisors.
One other configuration option available exports only internal flows. That option can exclude flows which are visible on an external physical switch, and prevents the duplication of traffic records for conversations into and out of the VDS. In most cases, it’s more useful to disable this option, and to see all flows that are visible to the VDS.
Configuring traffic from a VDS
We’ll need to start by adding the vCenter instance to Orion. NPM includes the code necessary to discover and poll the vCenter instance, but we’ll need to discover it first.
Navigate to “Manage Nodes” in the “Settings” menu, and select “Add Node.” You’ll enter the IP address or FQDN of the vCenter instance, and select “VMware, Hyper-V, or Nutanix entities” as the polling method.
Proceed through the add node dialog, adding the credentials of the vCenter instance and testing those to complete the configuration.
There is a time period to complete the initial polling for this instance; usually 10-20 minutes. Wait for that to complete before enabling IPFIX export from the VDS.
Once we’re monitoring the vCenter, we’ll enable our switch to export IPFIX records. For this, we’ll use the vSphere client to access the vCenter instance, and navigate to the “Networking” tab. Select your VDS, and you’ll find the current settings for “NetFlow” in the “Configure” tab, under “Settings.” In this context, VMware is using the term “NetFlow” generically to refer to flow export; the actual protocol they use is the IPFIX flow export format.
To enable flow export, select “Settings” from the “Actions” menu at the top, and navigate to “Edit NetFlow.”
In this dialog, you’ll enter the IP address of the collector – which is our Orion instance. You’ll also enter the port where the collector is listening; our default is usually port 2055. Our recommendation here is to leave the “Switch IP Address” blank – that will result in flow records which are sourced from the respective hypervisors. This gives you some flexibility to filter or alert by hypervisor.
As we mentioned earlier, we recommend you leave “Process internal flows only” disabled, which will give you visibility into all conversations, both internal and external.
Once you enable flow export for the DVS, you’ll also need to enable it for the distributed port groups you wish to monitor. The easiest way to do this is to right-click on the DVS in the navigation panel, and select “Distributed Port Group” – then, “Manage Distributed Port Groups.”
This will open a dialog to walk you through “Monitoring” configuration; just check that box, and hit “Next.”
In this next step, you can select specific port groups, or all port groups.
In the next step, you’ll toggle NetFlow to “Enabled”, and proceed.
With the VDS and the distributed port groups enabled for flow export, we should see flow records for our hypervisors begin to arrive in our NTA instance.
You can see your hypervisors listed as sources of flow data in the “Manage Flow Sources” page in NTA. Be sure to toggle to “Nodes.”
With this NTA release comes some fantastic new updates & enhancements to the Orion Platform which include:
Monitor up to 1,000,000 elements per Orion Platform instance.
For SAM components the limit is increased to be 550,000 components per SAM installation.
An Orion Map to Success! - Orion Maps improvements, such as creating and customizing text boxes, labels, or layouts, incorporating custom icons, adding shapes, dynamic backgrounds, bulk administration and all new Time Travel.
3rd Party Language Pack Support - scripts to extract UI texts from the Orion Web Console
Your Feedback Counts!
The team is incredibly interested in your feedback, and we'd like to hear more about your implementation experiences! Your consistent feedback really shapes our products; we are constantly reviewing your questions, comments, and experiences to come up with brand new feature ideas that we would want to consider for a future release. Visit our NTA Feature Requests area to tell us what you'd like to see.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community.
More than 150,000 members are here to solve problems, share technology and best practices, and directly
contribute to our product development process.