Product Blog

6 Posts authored by: brad.hale

In order to make the process of upgrading to NPM v11 as easy and seamless as possible, we have pulled together a number of resources to assist you.

The Benefits of Upgrading to NPM 11

  • Benefits of Upgrading to NPM 11:  In this 2-minute video, Rob Hock, SolarWinds group product manager, guides you through the newest features of NPM, deep packet inspection and analysis.




How to Deploy Packet Analysis Sensors


Over the course of the last few weeks we have held a number of webinars with customers about NPM version 11 and the new deep packet inspection and analysis capabilities.  Throughout those webinars, a number of common questions have come up.  Below you will find a list of FAQs that we hope will address most of those questions.


Q - We have an existing NPM license, can we freely upgrade to the latest version?

A - Yes, if you are an NPM customer under active maintenance then you can upgrade to version 11 free of charge and take advantage of the out-of-the-box packet analysis sensors.


Q - Is the upgrade from NPM 10.7 to NPM 11 seamless?

A - Yes, the upgrade process is a seamless process.


Q - Is Quality Of Experience and deep packet inspection and analysis included (free) with NPM v11?  Or does QoE require its own licenses?

A - The QoE dashboard and deep packet inspection and analysis are included out-of-the-box with NPM along with one network packet analysis sensor (NPAS) and ten server packet analysis sensors (SPAS).  Additional sensors can be purchased.


Q - If we already have an unlimited NPM license, am I still limited to 1 network sensor?

A - Yes, the one network and ten server sensors included out of the box apply to licenses of all sizes.  You can, however, purchase additional sensors to scale your deployment.


Q - What are the system requirements for NPM 11 and  the packet analysis sensors?

A - For your Network Performance Monitor server, the system requirements have not changed.  You can find them here  or in the Administrator Guide

For Packet Analysis Sensors the requirements are as follows:

Windows 7 / Server 2008 64-bit or later (32 bit operating systems are not supported)

2 CPU cores + 1 CPU core per 100 Mbps


1 GB (2 GB recommended) RAM

1 Gbps maximum throughput

Network Packet Analysis Sensors (NPAS) require a SPAN, mirror port, or in-line tap on the monitored switch


Q - What is a packet analysis sensor?

A - Packet analysis sensors are agents that capture and analyze network traffic packets.  They can be installed directly on an application server to capture and analyze the traffic from the application(s) on that server or they can be installed on a dedicated server connected to a switch SPAN port to capture and analyze the traffic on the SPAN port.


Q - Can sensors be used without installing any agents?

A - No, sensors are agents that reside on an application server or a dedicated server monitoring a SPAN port


Q - Can sensors be deployed to both 32 and 64 bit servers?

A - No, only 64 bit servers are supported.


Q - Would a mulit-homed server work as a sensor?

A - Yes


Q - What is the difference between a network sensor (NPAS) and a server sensor (SPAS)?

A - Network sensors (NPAS) reside on a dedicated server that is connected to a switch SPAN port and will capture and analyze application traffic that passes through the SPAN.

Server Sensors are deployed directly on a server that hosts an application that you would like to monitor traffic to and from and will monitor only the application traffic on that specific server.

Q - Are sensors limited to physical servers or can you use a virtual machine as a sensor?

A - Sensors can be deployed on a physical or virtual server.

Q - Does the sensor have to be on a computer with a 1GB NIC?

A - No, you do not have to have a 1GB NIC on your server, however, you will be limited to monitoring traffic at the throughput of your NIC.

Q - When doing a network sensor, can you use multiple interfaces?

A - Multiple interfaces may be spanned or mirrored to a network packet analysis sensor.

Q - Do the server sensors have to be on a dedicated server or can it be running other applications?

A - The server sensors are deployed directly on the server hosting the application.

Q - Does the sensor have to be on the same LAN as the SolarWinds server?

A - No

Q - Can sensors be run on the same Orion NPM server but with a dedicated NIC for the SPAN / mirrored port?

A - Yes

Q - Do we need to SPAN ports if all nodes and network sensor are in the same VLAN but in different switches?

A - You would need to SPAN ports on each switch.

Q - Is there a Linux agent/sensor?

A - Not at this time but we are looking at that for future releases

Q - Can I monitor Linux servers?

A - At this time there is not a Linux sensor.  It is something that is planned for future releases.  You can, however, monitor the application traffic from a Linux server through the connected switch using a network packet analysis sensor

Q - How many servers can be monitored by one network sensor?

A - There is no theoretical limit to the number of servers that can be monitored by one network sensor.  However, a single sensor is limited to monitoring 50 applications and a maximum of 1Gbps of throughput.

Q - Do you do application discovery?

A - Not at this time but we are looking at that for future releases

Q - How many application signatures are supported?

A - Over 1200

Q - Are these signatures updated dynamically through product updates?

A - Yes

Q - Can custom applications be defined?

A - Yes, custom HTTP applications can be defined.

Q - Are there any options for creating custom non-http application definitions?

A - Not at this time but we are looking at that for future releas

Q - Can QoE monitor SolarWinds Orion as one of the applications with variable response times?

A - Yes, using an HTTP application and/or a SQL applicaiton

Q - How does QoE impact the SQL database load?

A - There is a trivial impact on the SQL database load.

Q - What is the overhead at the Orion server level and at the monitored node?

A - There is minimal overhead on the Orion servers and typically a 10% overhead on the monitored node.

Q - How much detail is captured and what is the realistic amount of time it can be retained?

A - The only detail captured and retained is Application Response time, Network Response time, traffic volume and traffic count.  Retention time is configurable.

Q - How much additional bandwidth is required to send data back to the Orion server?

A - Minimal, since data is aggregated in 5 min intervals

Q - What ports are used by the server sensors to talk back to Orion?

A - TCP 17777 and 17778

Q - How best can I determine my sustained load?

A - Using the current interface statistics

Q - Do I need to use a separate database?

A - No

Q - Does the capture data stay on the Sensor host?  And what is the impact to storage/resource on the NPM host?

A - No payload data is stored

Q - How is DPI different from SAM?

A - Server and Application Monitor (SAM) provides up/down and performance monitoring for servers, and 150+ applications.  SAM does not monitor the response time or latency of an application so it has no concept of perceived end user experience or application quality of experience.  DPI and QoE, on the other hand, will provide the network and applicaiton response time that a user would experience.

Q - Is Server & Application Monitor (SAM) required?

A - No, SAM is not required, however, it does provide valuable additional insight into application status and performance.

Q - We have NPM, but not SAM, what would be the limit of the displays?

A - You would be able to determine that it's an application issue, but the drill-down would be limited to the high-level server metrics (CPU, memory, disk).  To get app performance and detailed server metrics (including HW health), you'd need to have SAM.

Q - Is AppInsight for SQL included with NPM 11 or do I need to purchase it seperately?

A - AppInsight for SQL is part of Server and Application Monitor (SAM).  It is purchased separately.

Q - How is QoE different from NTA?

A - NetFlow Traffic Analyzer (NTA) tells you how network bandwidth is being consumed but looking at the who, what, where, and how of bandiwdth utilization.  NTA has no concept of latency or user experience.  DPI and QoE, on the other hand will tell you how the end user is experiencing the application but not what the impact on network bandwidth is.

Q - Does NetFlow need to be enabled?

A - No, NetFlow is not required for DPI and QoE.

Q - Are you going to build the capability to ingest Cisco ART metrics from IPFIX?

A - It is under consideration.

Q - Are there any QoE report templates?

A - We have Top XX resources that can be used on reports

Q - Do you support Cisco RSPAN?

A - Not at this time.

Q - Can traffic be parsed between client machines and citrix vm/applications?

A - ICA traffic is supported.

Q - Can you monitor response time between remote client and specific server as opposed to from the NPM server to the app server?

A - Yes, that is default behavior.

Q - Can NPM measure application level jitter, errors, and packet loss?

A - Not with QoE at this time.  It can, however, be accomplished using VoIP and Network Quality Manager based on IP SLA technology.

Q - Do you have a sensor to detect rogue WiFi?

A - Not at this time.

Q - Does this support NetBios traffic?

A - Yes

Q - How is data deduplication handled? 

A - Data duplication is not possible presently, therefore no need to dedupe.

Q - How well does the network sensor work over a WAN link limited to 20Mbps or less?

A - There are no known issues.

Q - How does it deal with seeing the same packet at multiple points (e.g. if you are sniffing at a site as well as in a data center and seeing traffic passing through both points)?

A - Data duplication is not possible presently.

Q - How best would I deploy in a multi-switch environment?

A - See deployment guide

Q - I see signatures for YouTube and Skype.  Is QoE able to monitor these types of social traffic for a network link or only for a network node?

A - On a per node basis.

Q - Can Citrix traffic be decoded?

A - No, but we measure ICA response time.

Q - If using a VM stack, can QoE and NPM and NCM reside on the same host?

A - Yes

Q - If our NPM server resides in the same data center as the application server, will the results not be relative to local infrastructure and not remote users experience over the WAN?

A - No, relative to transaction between Client and Server


Q - In an environment where you have a number of VRFs where the same IP addresses can exist on the same device, can SolarWinds understand devices to both the VPN/VRF and device?

A - Devices need to be managed nodes, so as long as this requirement is fulfilled, there should be no issue


Q - How do additional polling engines impact deployment?

A - Sensors will send data to the assigned APE.


Q - Can the data collection and storage be configured?

A - QoE uses standard retention settings


Q - Is there a brand of TAP device that you would suggest?

A - We are aware of customers using Gigamon


Q - Would you want to place a TAP on each switch or on a core router

A - See deployment guide


Q - Is there an equivalent to a PCAP file that is being stored somewhere on the server?

A - No - all in memory


Q - Does NPM support the Nexus series from Cisco?

A - Yes


Q - Once all sensors are installed and reporting, is there a fair amount of configuration within the console for all of the information you have just shown to populate? Or does that information populate automatically?

A - Application response time, network response time, data volume and transaction count are all automatically calculated and displayed in the console with no configuration required.


Q - We use 10 Gig links in our Data Center and throughout our main office.  What can I do to use this product to monitor this 10 Gig network?

A - Using a hardware tap would be advised (EX: Gigamon)


Q - Is Nexus 1000v supported?

A - Yes


Q - Can NPM receive input from a Wireshark capture?

A - No, NPM does not take input from Wireshark.

Every day we are asked by customers, “Why do I need network change and configuration management (NCCM)?”   To that I like to reply, “Do you drive your car on the road without insurance?”  To me, NCCM is like having insurance for your network.  It protects you and makes your job a lot easier in case of network mayhem.




These are just a few examples of real-world unforeseen circumstances that can result in network downtime. 

SNMP Community Strings and Passwords – Have you ever had a network engineer leave your company (voluntarily or involuntarily) and then realize that he has the passwords and community strings for all of your devices?  Network management best practices suggest that you should change these every 30-60 days.  With SolarWinds NCM, you can simultaneously update all of your devices without requiring complex and error prone CLI commands using pre-defined change templates or by sharing with fellow network engineers on thwack.


Identify vulnerable devices – When Cisco releases a new PSIRT security vulnerability, do you have a way to determine which of your devices are vulnerable?



Backup! Backup! And Backup again! – Over 70% of all network issues are a result of faulty configurations.  By backing up device configs on a regular basis, you’ll always have a known good state that you can revert to.  In addition, with SolarWinds NCM, you can compare device configs side-by-side and see who changed what and when.


Receive real-time alerts – SolarWinds NCM allows you to quickly respond to unauthorized, unscheduled or erroneous changes by providing real time alerts and actions that can be integrated with NPM and customized to your needs.

Compliance – Ensuring that your device configs are compliant with internal, external and best practice policies gets the auditors off your back and makes your boss happy.  SolarWinds NCM includes a number of pre-defined policy violation reports or, again, you can share with the thousands of engineers on thwack.




Download now and see how SolarWinds Network Configuration Manager can protect you from network mayhem.








A few weeks ago, I told you how you can use NetFlow technology to diagnose the performance of your network and see who and what are talking on your network.  Now I want to share with you an additional technology that can be used to gain even deeper insight into network performance with a specific eye on WAN performance.


Using the IP SLA, a wicked cool technology as our Head Geek is fond of proclaiming, that is already built into most of your Cisco routers you are able to measure transport metrics from one device to another allowing you to isolate point-to-point performance issues. IP SLA generates time-based performance data while NetFlow generates volume-based data.  An IP SLA operation is analogous to putting a test car on a highway with specific instructions on where to go and then measuring whether it gets there (availability), the time it takes to get there (latency), and the space between the cars (jitter).


Let me give you a few use cases to better explain just how IP SLA measures your traffic performance.


Use Case 1: Monitoring WAN performance



An IP SLA operation is executed every 60 seconds between routers.  The operation reports back the availability of the connection, the packet transmit time (latency), packet loss and jitter.  By examining the statistics that come back between each point, you can determine where you may have a WAN issue that allows you to take further action.


Use Case 2:  Monitor end-to-end network quality


In this example, you create 4 different IP SLA operations to identify potential problem areas in your network.  First you check the overall response time from one end-point to another end-point (852ms).  Next you create additional operations that break the end-to-end response time into a series of smaller segments.  By examining each independent segment as it relates to the overall performance, you can again identify potential problem areas.


Use Case 3:  Verify Service Level Agreements (my personal favorite)


Perhaps you have a service level agreement with your WAN provider or maybe even internal SLAs that you need to meet.  So, how do you know if those SLA’s are actually being met?  Again, using IP SLA technology, you can measure your WAN performance and compare that to what you service provider is telling you.  If you were a good enough negotiator and have charge-back, refund or credit rights then you may be able to recover some money if those SLAs aren’t being met.  At a minimum it will give you some leverage the next time the contract comes up.


Use Case 4: Assessing VoIP and Video Infrastructure

With IP SLA you can monitor jitter across various parts of your network to determine if your infrastructure can handle deployment of voice and/or video over IP.


Hopefully you can see from the four use cases just how powerful IP SLA can be for monitoring the overall performance of your network. 


SolarWinds IP SLA Manager, a module of SolarWinds Network Performance Monitor, is a powerful solution for identifying site-specific and WAN related network performance issues using the built-in IP SLA technology found in most of our Cisco routers.


Learn more about SolarWinds IP SLA Manager.


How many times have you heard this?  How many times does it look like everything is fine to you?  If this is you, then read on. 

You’ve probably heard about NetFlow and you may have even seen it at a tradeshow, but what you may not know is that this core technology is built into your existing infrastructure. So, how can you use NetFlow to understand what’s really going on when you get the ‘it’s slow’ complaint?

Here’s the scenario: You’ve heard complaints from your users that the network is slow but you don’t know why or where.  You suspect it may be your WAN and/or internet links and you don’t want to simply increase bandwidth because that gets expensive quickly.  How do you create alerts so you are the first to know when you approach capacity and can hunt down bandwidth hogging users and applications before your boss hunts you down?


Step 1 - Manage your NetFlow sources and CBQoS Polling

From the NTA Summay tab, you will see your currently managed NetFlow Sources.



Click on Manage Sources and you can add, delete or edit your NetFlow Sources.




Step 2 – Manage Alerts     

Once you have set-up your NetFlow sources, you will use the advanced alerting features of NPM and NTA to create a “Top Talker” interface utilization alert that notifies you when certain thresholds are met, for example, High Transmit Percent Utilization or High Percent Receive Utilization.




Step 3 – Monitor Traffic

Once alerted that you have reached certain critical thresholds, or at any time, you can view “Top Talkers” within the Orion NetFlow console:



You are not limited to Top 10 conversations or applications; however, you can also see countries, endpoints, receivers, transmitters, IP Groups or protocols.

In addition, you can view your NetFlow sources by % utilization:




as well as create custom filtered views




Step 4 – Tell your boss it’s all under control

Now that you know who and what are consuming your network bandwidth, you can use the data to modify your network bandwidth, traffic policies and user behavior to optimize costs.


If you don’t already have Orion NetFlow Traffic Analyzer installed, you can learn more about it and Download a Free 30 Day Trial.


Stay tuned to part 2 where we will demonstrate how to determine the direct impact of network traffic consumption on your business critical applications using the IP SLA technology that is already built-in to your Cisco routers.

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.