Welcome to NPM v11!


It's finally here! Throughout the beta and RC process, there has been a ton of excitement around the new Quality of Experience (QoE) dashboard in NPM 11, and today the wait is over!

For those of you that may have missed it, the QoE dashboard captures packet-level data from sensors deployed in your environment, analyzes it and aggregates the information in a easy-to-read dashboard.

These statistics make it easy to tell at a glance not only if you have a user experience issue, but whether the issue is a problem with the network or the application.  In addition to response time statistics, we are capturing aggregate volume metrics, and have the ability to classify application traffic on your network by risk-level and relation to typical business functions.


QoE_Dashboard (1).png


Out of the box, NPM 11 is able to categorize ~1200 applications. Here we can see a sample of the Citrix applications we support (including ICA protocol):




Sensor Topology


So how are we able to gather this data? In NPM 11.0, we have the ability to deploy Packet Analysis Sensors (PAS) to Windows-based (64-bit / 2008+) systems. Sensors can be deployed in two configurations: "Server" or "Network."

With a "Server" PAS, the sensor is deployed directly on a server you would like to monitor. So for example, if you wish to monitor your Exchange response time / traffic, you would push the sensor directly to your Exchange server:


SPAS (1).png

For a "Network" PAS, the sensor is deployed to a dedicated Windows-based system with a dedicated interface attached to a tap / SPAN / mirror interface.


Once sensors are deployed, you can choose from our library of ~1,200 application signatures to monitor, or create your own custom HTTP applications.

Deployment Considerations

So now that we understand how we are gathering the data, where should we gather it from? Like many deep questions- it depends.

Are you a server admin looking for aggregate response time for your servers? Network admin wanting looking for client response time broken out by site? Both you say?

It's important to note that the PAS will report data aggregated at the server level, unless the individual client endpoints are also managed nodes in NPM. For example, in the case where we would want to see web server statistics from multiple remote sites, endpoints at those remote sites would need to be managed nodes in NPM (even as ICMP nodes.) From there, we could either deploy a SPAS to said endpoints, or use a NPAS anywhere in the traffic path to break out the individual response times.

If the application server is virtualized, you are presented with even more deployment choices for the NPAS. Do you create a virtualized NPAS and sniff the VDS? Create a promiscuous port group? VMWare has some good documentation on the hypervisor side of things: VMware KB: How promiscuous mode works at the virtual switch and portgroup levels  :: How to use Port-Mirroring feature of VDS for monitoring virtual machine traffic?

For more information- please check out our QoE deployment guide.


How are sensors licensed?

Out-of-the-box, a licensed version of NPM comes with 1 NPAS and 10 SPAS licenses. For most small-to-mid sized deployments, this should be sufficient to monitor critical infrastructure. Beyond the built-in licenses, NPAS and SPAS are licensed individually (NPAS) and in packs of 10 (SPAS)

How is NRT / ART calculated?

Short answer: magic. Long answer is a bit more complicated . Check out this video presentation by certified Wireshark© network analyst Jim Baxter: Deep Packet Analysis & Quality of Experience Monitoring - YouTube


How is an application classified?

Short answer again: magic. Long answer is: it depends on the application. Out-of-the-box NPM ships with ~1200 application signatures that use a variety of techniques beyond the typical port & protocol matching you may find in other solutions. Some examples of techniques used:

  • Statistical Pattern Matching
  • Conversation Semantics
  • Deep Protocol Dissection
  • Behavior Analysis
  • Future Flow Awareness


Can I create my own applications?

In NPM 11, we have the ability to create custom HTTP applications. In the future we may look at the definition of custom applications via port & protocol.

7-28-2014 5-31-03 PM.png

How much traffic can a sensor handle?

Both NPAS and SPAS are rated to a sustained 1Gb/s given sufficient resources. (Check out the deployment guide for more detailed information, but good rule of thumb is 1 CPU core per 100Mb sustained traffic.)

Without using a specialty hardware appliance, this is a pretty impressive number.

How many applications can I monitor per sensor?

The recommended maximum is 50 applications per sensor. Beyond this, performance results may vary.

How many sensors can an Orion instance handle?

The current maximum number of sensors an instance can handle is 1,000.

Learn more
For customers under active maintenance, NPM 11 may be found in your SolarWinds Customer Portal.

Release notes for NPM 11.0 may be found here: SolarWinds Network Performance Monitor Release Notes

Sign up for SolarWinds lab, where the topic of discussion will be the new QoE functionality: July 30th, 1PM CT - LAB #16: Deep Packet Inspection Comes To NPM