This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Introducing the NTA 2020.2 Release Candidate - VMware VDS Support

Welcome to our latest iteration of the NetFlow Traffic Analyzer, available now in your customer portal

Each release candidate is a fully tested and supported version of the product and you can upgrade current production servers, while retaining your complete configuration and history.

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 Release Candidate. 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 VMwareRegistered 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.

Screen Shot 2020-04-24 at 4.04.18 PM.png

Proceed through the add node dialog, adding the credentials of the vCenter instance and testing those to complete the configuration.

Screen Shot 2020-04-24 at 4.01.06 PM.png

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.

Screen Shot 2020-04-24 at 4.10.13 PM.png

To enable flow export, select “Settings” from the “Actions” menu at the top, and navigate to “Edit NetFlow.”

Screen Shot 2020-04-24 at 4.10.47 PM.png

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.”

Screen Shot 2020-04-24 at 4.20.27 PM.pngScreen Shot 2020-04-24 at 4.21.37 PM.png

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.

Screen Shot 2020-04-24 at 4.22.20 PM.png

In the next step, you’ll toggle NetFlow to “Enabled”, and proceed.

Screen Shot 2020-04-24 at 4.52.41 PM.png

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.

Screen Shot 2020-04-27 at 12.39.15 PM.png

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.”

Screen Shot 2020-04-27 at 12.53.59 PM.png

Configuring a new VDS in your environment is beyond the scope of this document; we suggest that you consult the VMware documentation for resources to configure a new VDS. This may be a good starting point:

More NTA Goodness

This is one of three articles on the 2020.2 NTA Release.  Here's the complete set, for your handy reference:

NTA VMware Distributed Switch support

NTA IPAM IP Group Integration

NTA Node Traffic Reconciliation


New Orion Platform Features

With this NTA RC 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.
  • Performance enhancements
  • Dashboards, Dashboards, Get Your Dashboards! All New Custom Summary Dashboards
  • A Gateway To Your Fastest Upgrade Ever! - Upgrade improvements, such as pre-staging upgrades, upgrade plan reports, automating upgrades via Orion SDK
  • Enhanced volume status
  • 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  when you participate by downloading and installing the RC, you'll receive THWACK points. More importantly - your feedback shapes our products. Post your thoughts, questions and concerns into the NTA Release Candidate area  and not only will you be able to get some SolarWinds swag, but we'll be watching for input to continuously drive product improvements. In addition, sometimes you'll 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.