Product Blog

6 Posts authored by: jreves Employee

In our latest release of User Device Tracker (UDT), you'll discover new port discovery and polling support for Cisco Nexus switching equipment. You'll also see UDT make a cameo appearance in our Network Insight™ for Palo Alto firewalls, with new visibility for devices connected to these firewalls. We'll show you where it integrates today into NPM.

 

Speaking of discovery, we've completely reworked the port discovery process to be very similar to node discovery. We'll show you what it looks like, and how to configure credentials for these new device types.

 

Finally, we'll talk briefly about some Orion® Platform enhancements, and improvements to the SDK we've recently published for working with ports.

 

Discovering and Importing Ports

 

In this release, we're adding some significant granularity in the Discovery and Import process for ports. The experience and the workflow is similar to the NPM node discovery, with granular selection criteria and port-filtering options:

 

It's simple to exclude operationally or administratively down ports from the import. This flexibility saves overhead and simplifies licensing by offering better, granular control.

 

Configuring Access for UDT

For most devices supported by UDT, all that's necessary are the SNMP credentials. For some devices—the Cisco Nexus 5K, 7K, and 9K series switches, or for the Palo Alto Firewall—a set of command-line interface (CLI) credentials are required.

 

You can configure devices in bulk or individually in the Port Management section of the User Device Tracker settings page.  Select "Manage Ports" to see the list of devices which can be configured:

 

Select one or more of these devices, edit their properties, and you'll find a section for configuring SNMP polling:

You'll also find a section for CLI-based polling:

The polling interval is set in its own section of the UDT Settings page, under "Polling Interval." The default polling interval for port information is 30 minutes.

 

Once you’ve enabled UDT Layer-3 polling for a CLI-based device, you can expect to see port information populated in the Port Details resource on the Node Details page.

 

UDT SDK Updates

This release adds some basic create, read, update, and delete operations for UDT ports into the Orion SDK. Refer to the documentation available in GitHub for examples.

 

 

Platform Improvements

Along with all of the other modules in the Orion Platform, UDT can be installed now in Azure, and make use of the native Azure SQL database service to host the Orion database. This adds additional deployment flexibility—we already support deployment in AWS using the RDS service.

 

How Do I Get This Goodness?

For UDT, you can find the latest release in your Customer Portal.

 

 

To see all the features of Network Insight for Palo Alto, you’ll want to have several modules installed and working together.

  • Network Performance Monitor discovers and polls your Palo Alto firewall and retrieves and displays your site-to-site VPN and GlobalProtect client VPN connection information.
  • Network Configuration Manager collects your device configuration and provides a list of your security policies for zone-to-zone communication. This module tracks configuration changes over time and provides context for policies spanning multiple devices.
  • NetFlow Traffic Analyzer collects flow data from the firewall and maps the traffic to policies in the Policy Details page. You can also view traffic through the firewall or through specific interfaces.
  • User Device Tracker collects directly connected devices and provides a history of connections to the ports on the device.

 

 

You can demo these products individually or install/upgrade from any installer available in your Customer Portal.

 

We're looking forward to hearing your feedback and questions on the release in the forum below!

VoIP & Network Quality Manager version 4.6 builds on the SIP trunk monitoring work we introduced in the previous release. In the last release, we introduced SIP trunk health and availability metrics monitored from the Cisco Unified Call Manager element. In this release, VNQM delivers SIP trunk call metrics—with on-demand polling—and SIP trunk utilization from the Cisco Unified Border Element. It's comprehensive visibility throughout the CUCM environment.

 

Monitoring the CUBE

 

You'll notice there's a new resource available on the VoIP Summary Page—"VoIP Gateways." These are the border gateway elements where SIP trunks terminate.

 

In this release, we support the Cisco Unified Border Element, or “CUBE” appliance.

 

The Call Manager hosts, visible in the VoIP CallManagers resource, drill down into details pages for each call manager. The VoIP Gateways expand directly into a list of SIP trunks.

 

 

 

At this level, you can see a quick status for each trunk. Drilling into one of the trunks provides this view.

 

 

The SIP Trunk Details view provides resources for monitoring status over time, metrics for inbound and outbound call activity, and SIP trunk utilization. Each of these metrics can be individually opened in a new PerfStack™ project, or the collection of status and call metrics for this trunk can be opened from the summary resource. In PerfStack, the "Performance Analyzer" view looks like this.

 

Pulling these metrics into PerfStack gives you visibility on the same timescale for other related metrics—resources on the CUBE device, for example.

 

 

Or, perhaps the active inbound and outbound calls for several trunks.

 

 

The PerfStack dashboard gives you the flexibility to compose views that you can save and use for monitoring or troubleshooting in the future.

 

Immediate Real-Time Polling

Note that the Inbound and Outbound call metrics from the CUBE have the "rocket ship" icon next to them to denote real-time polling is available. This means we can enable continuous polling and presentation of these metrics from the CUBE when we're troubleshooting issues, and we need to see the current call metrics from the perspective of the CUBE. This is a valuable insight into the key utilization metrics for each SIP trunk.

 

SIP Trunk Utilization

Tracking SIP trunk utilization is complex; there are several different factors to calculate utilization. Utilization depends upon the mix of typical calls, the codecs used in the environment, and the number of active calls. In this release, we're using maximum concurrent calls as the primary indicator of utilization, and calculating and presenting a percentage value useful for capacity planning. You should work with your SIP provider to estimate the number of concurrent calls your trunks can support and configure your thresholds accordingly.

 

To configure the maximum concurrent calls we'll use in the utilization calculation, you'll need to visit global settings for "VoIP & Network Quality Manager (VNQM) Settings," and select "Edit VoIP & Network Quality Manager Settings" to see these global values for "Gateway" settings.

 

In addition to the "Maximum Concurrent Calls," you can also set thresholds, polling intervals, and retention period for these metrics here.

 

CLI credentials are configured at the CUBE level by selecting "Manage Gateways" and providing credentials for one or all gateway devices.

 

 

You can also override the maximum concurrent call value in the CUBE properties.

 

The default out of the box value is 100 concurrent calls. You'll want to confirm this for your environment with your SIP trunk provider.

 

 

Platform Improvements

Along with all the other modules in the Orion® Platform, VNQM can be installed now in Azure, and make use of the native Azure SQL database service to host the Orion database. This adds additional deployment flexibility; we already support deployment in AWS using the RDS service.

 

We're excited to provide comprehensive health, availability, and utilization monitoring for SIP trunks in the Cisco CUCM environment. Visit your Customer Portal to review the Release Notes, verify the System Requirements, and download this release.

 

 

We're looking forward to your experiences and questions in the forum below.

In our latest release of NetFlow Traffic Analyzer (NTA), we’re focusing on features that deliver expanded visibility, and flexible evaluation and deployment options. For the first time, NTA is providing a significant contribution to our Network Insight™ feature for Palo Alto firewalls.

 

Also, in this release, we’re adding support for IPv6 flow records, and enhancing our filtering to display IPv4 only, IPv6, or both types of traffic.

 

For evaluation customers—and for current customers upgrading—we’ll automatically configure a local source of NetFlow data on the local server. This will provide an immediate source of data for evaluation installations and a comprehensive source of information for traffic sourced or destined to the primary poller.

 

Finally, we’re fully supporting the deployment of NTA into Azure, using the native Azure SQL Database service to host the flow database. This builds upon our existing support for deployment in AWS, using the native RDS service.

 

We’ll explain an important upcoming change in the upgrade process, and how to plan for it.

 

Traffic Visibility by Policy

 

In this release, NTA is contributing to our latest Network Insight through an integration with Network Configuration Manager (NCM). Users of SolarWinds NCM with Palo Alto firewalls will see top traffic conversations by security policy on the NCM Policy Details page. Examining traffic by policy helps answer the question, "Who might be affected as I make changes to my security policies?"

 

Let's look at how we find this view.  We'll start at the Node Details page for this firewall:

 

 

We'll use the slide-out menu in this view to select "Policies." This will take us to a list view of all the policies configured for zones on this device.

 

Selecting a policy from this list brings us to the Policy Details page:

Close

 

Policies define security controls between zones configured on the firewall. For a Palo Alto firewall, a zone can include one or more interfaces. So, in this view, we're looking at all the conversations based on applications defined in the policy.

 

It's a very different way of looking at conversations; this isn't a view of all traffic through a node or an interface. Rather, it's a view that relates to the policy definition, so the endpoints in these conversations are running over the applications on which your security rules are based.

 

The mechanism here is filtering; we’re looking at application traffic that references the application IDs in your security policy. So, the endpoints in those conversations may be from any zone where you’re using this policy.

 

For an administrator considering changes at the policy level, this is a valuable tool to understand how those rules apply immediately to production services and what kinds of impacts changes to them will have.

 

For this feature, you'll need both NCM and NTA. NTA, of course, requires Network Performance Monitor (NPM). NCM provides us the configuration information that includes the policy definition and the applications definitions. NTA reads application IDs from the flow records we receive from the Palo Alto firewall, and correlates those with the policy configuration to generate this view. With NTA, you can also easily navigate to more conventional node or interface views of the traffic traversing the firewall, and we integrate traffic information seamlessly into the Node Details page in NPM as well.

 

IPv6 Traffic Visibility

 

This release offers comprehensive visibility in mixed IPv4 and IPv6 environments, and the flexibility to isolate TopN views in each of these protocols. While deployment of IPv6 has not been aggressive as some originally predicted, it's gaining some significant traction in the public sector, large-scale distribution operations, universities, and companies working with IoT infrastructures. Our latest release consumes NetFlow v9 and IPFIX flow templates for IPv6 traffic and stores those records along with the IPv4 flow records we support today. Let's see what the NTA summary page looks like.

 

You'll notice some IPv6 conversations, and some IPv6 endpoints in the TopN views. This view gives you complete visibility into the traffic driving your utilization in a mixed IPv4 and IPv6 environment. We've also added new filters, both on the dashboard and in the flow navigator.

 

Close

 

These filters give you the flexibility to examine how traffic running over each version drives utilization, and which conversations are dependent on different configurations within the infrastructure.

 

The Orion® Platform—and NTA—already support installation on dual-stack IPv4 and IPv6 servers. You can receive these flow records on either an IPv4 or IPv6 interface, depending on how your server is connected.

 

IPv6 changes how we think about the security model. This visibility gives us a perspective on how our security polices act on IPv4 and IPv6 traffic to permit or deny conversations. In that sense, it's a valuable tool to confirm your traffic is compliant with your security policies.

 

Local Source of NetFlow

 

This release will automatically add a new source of NetFlow data to your NTA main poller. This new source is a composite of physical network interfaces on your Orion main poller represented as a special type of virtual interface: Local NetFlow Source. This new source of flow information gives you unprecedented visibility into the traffic that originates on or arrives to the Orion server. You can use this to answer questions about your network and system management traffic trends. "How much SNMP traffic does my monitoring generate? What volumes and frequencies of flow traffic do I receive, and from where? How much DNS traffic does my management platform drive, and to where?"

 

Let's see what this looks like.

Close

 

Selecting the "Local NetFlow Source" interface and drilling into it, here's the view.

 

Close

 

You can manage this source of traffic the same way you manage any other source of flow data: by selecting the "Manage Sources" link in the NetFlow Sources resource.

 

Close

You can enable or disable the Local NetFlow Source here to include or exclude traffic from this source.

 

For brand-new installations of NTA, this new source will be created and enabled by default. If you’re working with an evaluation copy of the NTA application, this will give you immediate live data in the product that's personal to your network. It's a great way to introduce your colleagues to new versions or evaluate new releases without having to reconfigure your network devices to send flow records to this instance.

 

If you’re upgrading NTA, this source will be created but will not be enabled by default. We'll respect your existing configuration and give you the flexibility to make the choice about whether you'd like to include this traffic in your current view. Disabling this source completely shuts down capture of traffic on the local interfaces.

 

Creating this interface consumes a single node license for both NPM and NTA. If you would prefer not to use a node license for local NetFlow source, you can completely delete this interface to release the license. You cannot, however, add this interface back later.

 

Azure Deployment

 

Finally, we've been working to ensure users deploying into Azure can make use of the native Azure SQL Database service for both the common Orion database and the SQL NTA database. You'll be able to specify Azure SQL Database to build both of these databases during installation, in much the same way as you build in existing SQL instances today. We're supporting additional choices to help lower operational costs and expand your deployment flexibility.

 

To take advantage of this option, you’ll enter the connection string for your Azure SQL Database instance much the same way you enter any other connection string in the Configuration Wizard.

 

AzureCW.png

 

Changes in the Upgrade Process Are Coming

 

If you’re upgrading to NTA 4.6 from an older version of the product, you’ll once again see a familiar option to defer your NTA upgrade and remain on a version that doesn’t require SQL 2016 or later for the flow database.

 

In the past three releases of NTA (4.4, 4.5, and 4.6), we’ve included a pre-flight check in the upgrade dialog to allow customers to defer the upgrade and retain (or upgrade to) NTA version 4.2.3, the latest version that supports flow storage in the FastBit database. This in turn allowed updates to the Orion Core and other product modules without requiring an NTA upgrade. 

 

In the next release of NTA, this option will no longer be available. An upgrade to the next release of NTA after 4.6 will require a SQL 2016 or later database (or appropriate AWS RDS or Azure SQL option) to complete the upgrade.

 

A modern version of SQL supports columnstore technology, which provides significant performance and scale benefits for NTA. We’re building on this technology in every new release to drive better performance and a better user experience.

 

You should plan now for your next upgrade to deploy a SQL 2016 or later instance for flow storage. Refer to the NTA System Requirements documentation for supported options.

 

How Do I Get This Goodness?

 

For NTA, you can find the latest release in your Customer Portal. Remember, we also have a terrific complementary set of free NetFlow tools in the Flow Tool Bundle, including Flow Replicator, Flow Generator, and Flow Configurator.

 

To see all the features of Network Insight for Palo Alto, you’ll want to have several modules installed and working together.

 

  • Network Performance Monitor discovers and polls your Palo Alto firewall and retrieves and displays your site-to-site VPN and GlobalProtect client VPN connection information.
  • Network Configuration Manager collects your device configuration and provides a list of your security policies for zone-to-zone communication. This module tracks configuration changes over time and provides context for policies spanning multiple devices.
  • NetFlow Traffic Analyzer collects flow data from the firewall and maps the traffic to policies in the Policy Details page. You can also view traffic through the firewall or through specific interfaces.
  • User Device Tracker collects directly connected devices and provides a history of connections to the ports on the device.

 

You can demo these products individually or install/upgrade from any installer available in your Customer Portal.

 

Post your questions and experiences in theNetFlow Traffic Analyzer community forum!

Woes of Flow

A poem for Joe

 

It uncovers source and destination

without hesitation.

Both port and address

to troubleshoot they will clearly assess.

Beware the bytes and packets

bundled in quintuplet jackets,

for they are accompanied by a wild hog

that will drown your network in a bog.

The hero boldly proclaims thrice,

sampling is not sacrifice!

He brings data to fight

but progress is slow in this plight.

 

Mav Turner

 

As network operators, one of the most common—and important—troubleshooting tasks revolves around tracking down bandwidth hogs consuming capacity in our network infrastructure. We have a wealth of data at our fingertips to accomplish this, but it’s sometimes challenging to reconcile into a clear picture.

 

Troubleshooting high utilization usually begins with an alert for exceeding a threshold. In the Orion Platform’s alerting facility, there are several conditions we can set up to identify these thresholds for action. The classic—and simple—approach is to set a threshold for utilization defined as a percentage of the available capacity. The Orion Platform also supports baselining utilization in a trailing window and setting adaptive thresholds. Next, you need to investigate to determine what’s driving utilization and decide what action to take.

 

Usually, the culprit is a particular application generating an unusual level of traffic. We can get some insights into application traffic volumes from a NetFlow analyzer tool like NetFlow Traffic Analyzer.

 

So, why don’t the volume measurements match exactly from these two sources of data? Aren’t interface utilization values the same as traffic volume data from NetFlow?

 

Let’s review the metrics we’re working with, and how this data comes to us.

 

Interface capacity—the rate at which we can move data through an interface—is modeled as an object in SNMP, and we pick that up from each interface as part of the discovery and import process into Network Performance Monitor network monitoring software. It can be overridden manually; some agents don’t populate that object in SNMP correctly.

 

Interface utilization is calculated from the difference in total data sent and received between polls, divided by the time interval between polls. The chipset provides a count of octets transmitted or received through the interface, and this value is exposed through SNMP. The Orion Platform polls it, then normalizes it to a rate at which the interface speed is expressed. That speed is usually “bits per second.”

 

SNMP Polled Utilization

 

The metrics reported by SNMP about data received or sent through the interface includes all traffic—layer two traffic that isn’t propagated beyond a router, as well as application traffic that is routed. Some of the data that flows through the interface isn’t application traffic. Examples include address resolution protocol traffic, some link-layer discovery protocols, some link-layer authentication protocols, some encapsulation protocols, some routing protocols, and some control/signaling protocols.

 

For a breakdown of application traffic, we look to flow technologies like NetFlow. Flow export and flow sampling technologies are normalized into a common flow record, which is populated with network and transport layer data. Basic NetFlow records include ICMP traffic, as well as TCP and UDP traffic. While it’s possible on some platforms to enable an extended template that includes metrics on layer 2 protocols, this is not the default behavior for NetFlow, or any of the other flow export protocols.

 

Top N Applications traffic volumes

 

The sFlow protocol takes samples from layer 2 frames, and forwards those. So, while it’s possible to parse out layer 2 protocols from sFlow sample packets, we generally normalize sFlow along with the flow export protocols to capture ICMP, TCP, and UDP traffic, and discard the layer 2 headers.

 

When we work with flow data, we’re focusing on the traffic that is generally most variable and represents the applications that most often drive that high utilization that we’re investigating. But you can see that in terms of the volumes represented, flow technologies are examining only a subset of the total utilization we see through SNMP polled values.

 

SNMP Polled versus application flow volumes

 

An additional consideration is timing. SNMP polling and NetFlow exports are designed to work on independent schedules and are not synchronized by design. Therefore, we may poll using SNMP every five minutes and average the rate of bandwidth utilization over that entire period. In the meantime, we may have NetFlow exports from our devices configured to send every minute, or we may be using sFlow and continuously receiving samples. Looking at the same one-minute period, we may see very different values at a particular interval for interface utilization and application traffic that is likely the main driver for our high utilization.

 

SNMP Polling and flow export over time intervals

 

If we’re using sFlow exclusively, our accuracy can be mathematically quantified. The accuracy of randomly sampled data—sFlow, or sampled NetFlow—depends solely on the number of samples arriving over a specific interval. For example, a sample arrival rate of ~1/sec for a 10G interface running at 35% utilization and sampling at 1:10000 yields an accuracy of +/-3.91% for one minute at a 98% confidence interval. That accuracy increases as utilization grows or over time as we receive a larger volume of samples. You can explore this in more detail using the sFlow Traffic Characterization Worksheet, available here: https://thwack.solarwinds.com/docs/DOC-203350

 

So, what’s the best way to think about the relationship between utilization and flow-reported application traffic?

 

  • Utilization is my leading indicator for interface capacity. This is the trigger for investigating bandwidth hogs.
  • Generally, utilization will alert me when there’s sustained traffic over my polling interval.
  • Application traffic volumes are almost always the driver for high utilization.
  • I should expect that the utilization metric and the application flow metrics will never be identical. The longer the time period, the closer they will track.
  • SNMP-based interface utilization provides the tools to answer the questions:
    • What is the capacity of the interface?
    • How much traffic is being sent or received over an interface?
    • How much of the capacity is being used?
  • Flow data provides the tools to answer the questions:
    • What application or applications?
    • How much, over what interval?
    • Where’s it coming from?
    • Where is it going?
    • What’s the trend over time?
    • How does this traffic compare to other applications?
    • How broadly am I seeing this application traffic in my network?

 

Where can I learn more about flow and utilization?

 

An Overview of Flow Technologies

https://www.youtube.com/watch?v=HJhQaMN1ddo

 

Visibility in the Data Center

https://thwack.solarwinds.com/community/thwackcamp-2018/visibility-in-the-data-center

 

Calculate interface bandwidth utilization

https://support.solarwinds.com/Success_Center/Network_Performance_Monitor_(NPM)/Knowledgebase_Articles/Calculate_interface_bandwidth_utilization

 

sFlow Traffic Characterization Worksheet

https://thwack.solarwinds.com/docs/DOC-203350

We’re delighted to announce the release of version 4.5 of NetFlow Traffic Analyzer (NTA)!

 

The latest release of SolarWinds® NetFlow Traffic Analyzer is designed to help create alerts based on application flows. In past releases, we could alert on the overall utilization of an interface and provide a view of the top talkers when the configured threshold was exceeded. In this release, you can set a threshold on the volume of a specific application in order to trigger an alert. We're making use of the Orion Platform alerting framework, so that flexibility is available to you.

 

You’ve outlined a small set of critical problems in multiple requests, and in this release, we’re delivering on the five most popular of these.

 

  • Application traffic exceeds a threshold – Alert triggered when we observe a specific application rate exceeds a user-defined threshold
  • Application traffic falls below a threshold – Alert that can provide visibility when an application “goes off the air” and stops communicating
  • Application traffic appears in the “TopN” list of applications – This alert triggers when application traffic increases suddenly relative to other applications
  • Application traffic drops from the “TopN” list of applications – Likewise, alert triggers for a sudden reduction relative to other applications
  • Flow data stops from a configured flow source – Alerts on the loss of flow instrumentation, and prompts to take action to help restore visibility

 

Contextual Alerting

The approach we're using to create alerts is built to guide users into a particular context—a source of flow where we see the application traffic—and then offers a simple user experience to create the alert.

To create an alert based upon any these triggers, we must first select a source of flow data as a point of reference. We can do these one of two ways.

 

We can visit the NTA Summary Page, and navigate to a particular source of flow data:

 

 

If the application of interest is in the TopN, we can expand it to see where this application is visible and select that source. That will take us to a detail page, which is already filtered by both application and source of the flow data.

 

We can also select our source of flow data directly in the Flow Navigator. We can build our alert based upon a node that reports flow, or upon a specific interface:

 

 

Once we have a context for an alert, we can select an application. If we use the "TopN Applications" resource, we have already identified both the application and the node or interface where it's visible.

Another way to arrive at this context can make use of the Flow Navigator, where we can explicitly select the application we’re interested in:

 

 

 

We can select either Applications, or NBAR2 Applications, to help describe the traffic. With the context now fully described, we are able to open the "Create a Flow Alert" panel and create our first alert:

 

 

At the top of the panel, we'll see the source of the flow data that we'll evaluate, and a default alert name prefix. We can customize the alert name to help make searching simpler. The severity of the alert is configurable:

 

For the Trigger Condition, we'll select one of the options described above. In this case, we'll select "Application Traffic exceeds Threshold," and we'll set a threshold of 50MBps on the ingress. We'll evaluate the last five minutes of traffic; this is configurable. This threshold will trigger when our traffic rate averages greater than 50MBps over the five min. time period.

 

Finally, we can specify one or several protocols; if we specify more than one, we'll sum the traffic volumes for all the protocols.

 

To create the alert, there are two options. We can select the "Create Alert" immediately, and this will simply log the alert when it triggers. Or, we can check the box to open the alert in the Advanced Alert Editor and then select "Create Alert." Selecting this option will redirect us to the last step in the "Add New Alert" wizard, where we can modify the trigger actions, reset actions, or time of day schedule.

 

 

The trigger condition is an advanced SWQL query, pre-populated with the contextual information on the source and application.

 

Before submitting this new alert, we'll see a message indicating whether the alert will trigger immediately.

 

Practical Alert Scenarios

Use the "exceeds threshold" alert for application traffic levels that average above or below the specified threshold.

Use the operation for ">" (greater than) or "<=" (less than or equal to) to determine then you can alert above or below the threshold. For example:

  • To determine when backup application traffic is running out of schedule
  • To identify large file transfers in the middle of the day
  • To identify DDOS attacks, or when Port 0 traffic is present at all

Use the <= “exceeds threshold” to help detect when an application server process goes offline and stops sending traffic.

  • The application service may have crashed
  • An intermediate connectivity problem (firewall or outage) may have reduced traffic

Use alerts related to applications appearing in—or dropping out of—the TopN can be useful for detecting sudden changes in traffic volume relative to other applications. Examples include:

  • Detecting streaming or peer-to-peer file sharing applications that are transient
  • Detecting changes in the mix of applications that usually traverse an interface

 

You can also set up an alert for each of your NetFlow sources to help take action if the configuration is modified, or firewall rules block flow traffic.

 

User Experience Improvements

This release of NTA also includes a number of small but significant improvements in the user interface to help enhance scalability and improve ease of use. Several long lists are now uniformly ordered, and we’ve changed how we label certain features to be clearer in the navigation.

 

Additional Resources

Check out the Release Notes, download the new release on the Customer Portal, and get additional help with the upgrade at the Success Center.

 

You can see these new features in action in the webcast, “Up, Down, and Gone: A Tale of Applications and Flow.”

 

This is an initial introduction of the traffic alerting feature. Be sure to enter additional feature requests and expanded functionality that you'd like to see with this capability!

 

jreves

NetFlow Traffic Analyzer

Faster. Leaner. More Secure.

 

The new NetFlow Traffic Analyzer leverages the power of columnstore technology in MS SQL Server to deliver answers to your flow analysis questions faster than ever before. MS SQL 2016 and later runs in a more efficient footprint than previous flow storage technologies, making better use of your infrastructure. Support for TLS 1.2 communication channels and monitoring of TCP and UDP Port 0 traffic helps to secure your environment.

 

Version 4.4 also introduces a new installation process to confirm that you have the necessary prerequisites, and to guide you through the installation and configuration process.

 

NTA 4.4 is now available in the Customer Portal. Check out the Release Notes for an overview of the features.

 

Faster

The latest release of NTA makes use of Microsoft’s latest version of their SQL columnstore based flow storage database.  Columnstore databases organized and query data by column, rather than row index. They are the optimal technology for large-scale data warehouse repositories, like massive volumes of individual flow records. Our testing and our beta customer experiences indicate that columnstore indexes support substantial performance improvements in both querying data, and in data compression efficiency.

 

NTA was an early adopter of columnstore technology to enhance the performance of our flow storage database. As Microsoft’s columnstore solutions have matured, we’ve chosen to adopt the MS SQL 2016 and later versions as the supported flow storage technology. That offers our customers the ability to standardize on MS SQL across the Orion platform, and to manage their monitoring data using a common set of tools with common expertise. We’ve made deployment and support simpler, more robust, and more performant.

 

Leaner

This same columnstore technology also runs more efficiently with the existing resource footprint. This solution builds and maintains columnstore indexes in memory, and then manages bulk record insertions with much less intensive I/O to the disk storage. CPU required to build indexes is also substantially less intensive than our previous versions. As a result, this version will make better use of the same resources to run more efficiently.

 

More Secure

This version of NTA supports TLS 1.2 communication channels, required in many environments to secure communications with client users.

 

Beginning in this version, NTA will explicitly monitor network flows that are destined to TCP or UDP service port 0. Traffic that’s addressed to TCP or UDP port 0 is either malformed – or malicious traffic. This port is reserved for internal use, and network traffic on the wire should never appear addressed to this port. By highlighting and tracking flows addressed to port 0, NTA helps network administrators to identify sources of malicious traffic that may be attacking hosts in their network, and providing the information they need to shut that traffic down.

 

NTA will surface port 0 traffic as a distinct application, so the information is available in all application resources.

NTA Port 0 Traffic

Supported Database Configurations

This version of NTA maintains a separate database for Flow Storage. NPM also maintains the Orion database for device and interface data. Both of these databases are built in MS SQL instances.

 

New installations of NTA and upgrades to version 4.4 and later will require an instance of MS SQL 2016 Service Pack 1 or later version for flow storage. For evaluation, the express edition is supported. For production deployments, we support the Standard and Enterprise editions.

 

When upgrading to this version from older version on the FastBit database, data migration is not supported. This upgrade will build out a new, empty database in the new MS SQL instance.  The existing flow data in the FastBit database will not be deleted or modified in any way. That data can be archived for regulatory requirements, and customers can run older product versions in evaluation mode to temporarily access the data.

 

In the current NTA product, we require a separate dedicated server for Flow Storage. The simplest upgrade would use that dedicated server with the new release to install an instance of MS SQL 2016 SP1 or later for flow storage. Many of our customers will be interested in running both the Orion database and the NTA Flow Storage database in the same MS SQL instance. We support that, but for most customers that will take some planning to consolidate and to appropriately size that instance to support both databases.

 

Here's a more detailed discussion of NTA's New MS SQL Based Flow Storage Database. Also, a knowledge base article on NTA 4.4 Adoption is available, with frequently asked questions.

 

We’re doing some testing now to provide some performance guidance for key performance indicators to monitor. One of the benefits of using MS SQL technology for both of these databases is that there are many common tools and techniques available to monitor and tune MS SQL databases. We plan to provide guidance for both monitoring, and deployment planning.

 

Conclusion

Please visit the NetFlow Traffic Analyzer Forum on THWACK to discuss your experiences and new feature requests for NTA.

Filter Blog

By date: By tag:

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.