Skip navigation

Product Blog

12 Posts authored by: cobrien Employee

NPM 12.2 was made available in the Customer Portal on September 13th!  The release notes are a great place to get a broad overview of everything in the release.  Here, I'd like to go into greater depth on  Network Insight for ASA including why we built it and how it works.  Knowing that should help you get the most out of the new tech!


Network Insight

We live in amazing times.  Every day new technologies are invented that change how we interact, how we build things, how we learn, how we live.  Many (most?) of these technologies are only possible because of the relatively new ability for endpoints to talk to each other over a network.  Networking is a key enabling technology today like electricity was in the 1800s and 1900s, paving the way for whole wave of new technologies to be built.  The better we build the networks, the more we enabling this technological evolution.  That's why I believe in building great networks.


A great network does exactly one thing well: connects endpoints.  The definition of "well" has evolved through the years, but essentially it means enabling two endpoints to talk in a way that is high performance, reliable, and secure.  Turns out this is not an easy thing to do, particularly at scale.  When I first started maintaining, and later building networks, I discovered that monitoring was one the most effective tools I could use to build better networks.  Monitoring tells you how the network is performing so you can improve it.  Monitoring tells you when things are heading south so you can get ahead of the problem.  Monitoring tells you if there is an outage so you can fix it, sometimes even before users notice.  Monitoring reassures you when there is not an outage so you can sleep at night.


Over the past two decades, I believe as a company and as an industry we have done a good job of building monitoring to cover routers, switches, and wireless gear.  That's great, but virtually every network today includes a sprinkling of firewalls, load balancers, and maybe some web proxies or WAN optimizers.  These devices are few in number, but absolutely critical.  They're not simple devices either.  Monitoring tools have not done a great job with these other devices.  The problem is that we mostly treat them like just another router or switch.  Sure, there are often a few token extra metrics like connection counts, but that doesn't really represent the device properly, does it?  The data that you need to understand the health and performance of a firewall or a load balancer is just not the same as the data you need for a switch.  This is a huge visibility gap.


Network Insight is designed to fill that gap by finally treating these other devices as first class citizens; acquiring and displaying exactly the right data set to understand the health and performance of these critical devices.


Network Insight for Cisco ASA

Network Insight for Cisco ASA is our second installment in the Network Insight story, following Network Insight for F5.  As you saw with F5, Network Insight for ASA takes a clean slate approach.  We asked ourselves (and many of you) questions like:


  • What role does this device play in connecting endpoints?
  • How can you measure the quality with which the device is performing that role?
  • What is the right way to visualize that data to make it easiest to understand?
  • What are the most common and severe problems that occur with this device?
  • Can we detect those problems?  Can we predict them?


With these learnings in hand, we built the best monitoring we could from the ground up.  Let's take a look at what we came up with.


Access Lists


ACLs define what traffic is allowed or blocked.  This is the most essential task of the firewall and monitoring tools generally don't provide any visibility.


The first thing we found here is there's no good way to get all of this data via SNMP.  We have to pull the config and analyze it.  For that reason, we handed this piece off to the NCM team to work on.  Check out more here: Network Configuration Manager 7.7 is now generally available!



Site to Site VPN


Site to site VPN tunnels are the next most important service that ASAs provide.  They are often used to connect offices to data centers, data centers to cloud providers, or one organization to a partner.


Yesterday, you could monitor these tunnels by testing connectivity to the other side of the tunnel, for example an ICMP monitor to a node that can only be reached through the tunnel.  Today, we poll the ASA itself via SNMP and API to show a complete picture including:

  • What tunnels are configured?
  • Are my tunnels up or down?
  • If a tunnel is up:
    • How long has the tunnel been up?
    • How much bandwidth is being used by the tunnel?
    • What protocols are securing the traffic transiting the tunnel?
  • If a tunnel is down:
    • How long has the tunnel been down?
    • What phase did the tunnel negotiation fail at?




This means we automatically detect and add VPN tunnels as they're configured or removed and constantly keep an eye on these very important logical connections.  I'll highlight a couple interesting things.




We're introducing a simple new concept called favorites.  Marking a tunnel as a favorite by clicking the star on the right does two things.  First, you can filter and sort based on this attribute.  The page by default shows favorite tunnels first, so you will always see your favorites first until you change the sorting method.  Second, it promotes that tunnel's status to the summary screen.  We found for most ASAs there were a couple of VPN tunnels that were wildly more important than all of the other tunnels.  Here at SolarWinds HQ for example, it's the tunnel to the primary data center.  At the primary data center, it's the tunnel to the secondary data center.  Favorties provide a super easy way to add extra focus to the tunnels that are so important that a big part of the story of the health and performance of the ASA is the health of the tunnels themselves.



Tunnel Status

What is the status of the tunnel?


Turns out this is a harder question to answer than it looks.  Tunnels are established on-demand.  If you just configured a tunnel, but have not sent any interesting traffic so the tunnel is not up, should we show it as down (red)?  That doesn't seem right.  What if the tunnel was up for 3 months, but interesting traffic stopped coming so the tunnel timed out and went back down, but is prepared to come back up as soon as interesting traffic is seen?  The tunnel is definitely "down", but should it be red?  Probably not!  We spent a lot of time thinking about this and talking to you guys to determine the logic that decides if an administrator considers a tunnel down, up, or something in between.  All of that logic is built into the statuses you see presented on this page.



For years, my first troubleshooting step on a tunnel that was down was to review logs and find out what phase negotiation failed at.  This tells you what set of variables you need to review for matching against your peer.  I'm very pleased that this first data point is now right in the monitoring tool that identified the tunnel as down to start with.  I hope it helps you guys get your tunnels back up faster.



Remote Access VPN


When users connect to the office using a software VPN client on their laptop, Cisco calls that Remote Access VPN.  As with Network Insight for F5, we are careful here to use the same terms as the manufacturer so it's easy to understand what we're talking about.


Again, we have to use both SNMP and API to get all the data we need to answer the following questions:

  • Who's connected?
  • Who tried to connect in the past, and what was the result?
  • How long have they been connected?
  • How much data have they uploaded and downloaded?
  • What is their session history?



Again, I'll highlight a few things.


List View

One of the challenges is the sheer number of remote access connections there are.  We know we do not do good enough job at dealing with very large lists today and our UI Framework team has been working on solving that.  This page is one of the first implementations of the new List View that they created.  This list view gives you the tools to easily deal with very large lists.  The left side of the screen lets you filter on anything shown on the right.  The filters available are considerate of the data and values seen on the right, so we don't have useless filters.  You can stack several filters and remove them individually.  Finally, after filtering your list you can still sort and search through those filtered results to further hone your list.



You'll see this list view a lot more as time passes.




Whereas interfaces are the main story on a switch or router, they're an important secondary story on an ASA.  We rebuilt the interfaces view from the ground up based on the List View.  Along the way, we made sure we were building it for a firewall.




As my fellow ASA Administrators know, nameif is not a typo.  Nameif is the command you use to specify the name of an interface on an ASA.  A nameif must be configured for an interface to function, and from the moment you specify the nameif onward, every other element in the interface references the nameif.  ACLs, NAT, you name it.  In other words, the identity of an interface on an ASA is its nameif (like CPLANE or OUTSIDE), not it's physical name (like GigabitEthernet0/2).  Accordingly, that is the primary name shown here, with the physical interface name shown only if the interface isn't in use and doesn't have a nameif.


Access Lists

If you have NCM to pull access lists from configs, we will identify which access list is applied to each interface and provide a link to review the access list.  This is super convenient in practice.


Security Level

Security levels have some control over what traffic the ASA allows.  It also provides a quick indicator of how much the administrator trusts the network connected to a specific interface.  Kind of important things for a firewall.



Again, we're using the simple favorites concept.  I expect a lot of ASAs to have the interface connected to the Internet favorited!





All of the things described above are technology services that are built on a platform.  The platform must be healthy for the services to have any chance of being healthy.  The platform sub-view helps you understand the health of the platform.



High Availability

While high availability is a feature of many platforms, it seems to be particularly popular on ASAs.  Additionally, it seems Administrators have to fiddle with it a lot.  Administrators have to failover to perform software upgrades, some choose to failover to change circuits, failover to upgrade hardware, failover for all sorts of reasons.  While I'm concerned we are all using failover so often, it is clear that NPM has to provide great coverage for H/A.


In speaking with lots of ASA administrators we found several different behaviors.  Some administrators were unaware of whether their ASAs were really ready for failover or not.  Some check manually every once in a while, but have had an active ASA go down only to discover failover could not occur.  Some expert administrators were checking failover status, but were also checking the quality of failover that would occur by verifying configuration synchronization and state synchronization.


Our H/A resources takes the best practices we found were being manually used by expert administrators, automates the monitoring of them, and presents simple conclusions in the UI.  If everything is green, you get simple checks and a phrase explaining what is healthy.  If something goes wrong, you get a red X more verbose explanation.  For example, if the standby is ready but the config is not in sync, failover can occur but the behavior of the firewall may change.  Maybe your last ACL change was not copied to the standby, so it doesn't apply if there is a failover.  If standby is ready but connection state information is not synced, failover can occur but all of your users will have to restablish their connections.  Not good!


Of course you can alert on all of these things.


Connection Counts

Firewalls store information about each connection that is actively flowing through them at a given moment.  Because of that, there is a limit to how many concurrent connections they can handle, and this is one of the primary values used to determine what size firewall you need to buy.  It's obvious then that it should also be a crucial part of how we understand the load of the device in addition to RAM and CPU, so we've included it here.


Aggregating connection failure rates is an interesting way to get an indicator that something is amiss.  Perhaps your firewall is blocking a DDOS or maybe a firewall rule change went awry.  Watching this one value can be a leading indicator of all sorts of specific problems.


Summary: Putting it all Together

If we've done our job, we're providing comprehensive coverage of the health and performance of an ASA on all of the sub-views.  Now, we pull all the information together and summarize it on the Summary page.



Details Widget

One of the things that really weighed down the Node Details page for most nodes was the Details resource.  This resource has historically been a catch all for lots of little bits of largely static data users have asked us to show on this page.  The problem is that it kept growing and eventually took up nearly half the page with data that actually wasn't that commonly needed.  Here we have rebuilt the resource to focus on the most important data, but with the additional data available within the "other details" drop down.  This also allowed us to move away from the archaic pattern of Name:value pairs in our UI.  Instead, we describe the device as your peer would.  You can see how the resource reads more like "this is <hostname>, the <context name> context on a <hardware model> running <software version>".


Also, did you know that what we called "resources" in the previous UI framework are called "widgets" in the new UI Framework?  There's your daily dose of useless trivia!


PerfStack Widget

Did you notice it?  The Load Summary and Bandwidth widgets on this page are powered by PerfStack charting.  Try clicking around on them.  It's oh so pleasant.  More to come on this later.



The Bandwidth and Favorite Site-to-Site VPN widgets display information about the components you identified as your favorites on the other pages.  I think it's about time we recognized that all VPN tunnels and all interfaces are not equally important.  Some are so critical that their status alone is a big part of the answer to the question: how is the firewall running?  Favorites makes it easy to give them the attention they deserve.


Setup Network Insight for ASA


To get this visibility in your environment, jump on over to the customer portal to download the new version.  After upgrading your NPM instance, the new ASA monitoring should "just work," but here's the specifics just in case.


Already monitoring ASAs?

The new monitoring will start up automatically.  Give the new version a couple minutes to poll and jump over to Node Details for one of your ASAs.  You'll get a bunch of new information out of the box.  For complete coverage as seen in the screenshots above, you'll be prompted to edit the node, check the "Advanced ASA" monitoring check box, and enter CLI credentials.  Make sure to look at the sub-views (mouse over to the left)!


There is one caveat.  If you've assigned a custom view to your ASAs, we will not overwrite that!  Instead, you will have to choose to manually change the view for your ASAs over to our new view.


Adding a new ASA?


Simply "Add Node" and select the "Advanced ASA" monitoring check box on the last step to enter CLI credentials.  That's it.  Give it a few minutes and check out the Node Details page for that ASA.




That does it for now.  You can click through the functionality yourself in our online demo.  I'd love to hear your feedback once you have it running in your environment!

Version 2.0 is a new major release of GNS3, which brings significant architectural changes and new features to the growing community of over 900,000 registered network professionals. Since inception of the project GNS3 has made over 79 releases and been downloaded over 13,693,000 times.


GNS3 started as only a desktop application from the first version up to version 0.8.3. With the more recent 1.x versions, GNS3 has grown to now allow for the use of remote servers. Within version 2.0, multiple clients can control GNS3 at the same time, also all the “application intelligence” has been moved to the GNS3 server.


What does it mean?


  • Third parties can make applications controlling GNS3. This will also allow individuals to easily configure and spin up a virtual network with pre-established templates

  • Multiple users can be connected to the same project and see each other modifications in real time, allowing individuals in remote location to work and collaboration on projects in the GNS3 virtual network environment

  • No need to duplicate your settings on different computers if they connect to the same central server.

  • Easier to contribute to GNS3, the separation between the graphical user interface and the server/backend is a lot clearer

  • GNS3 now supports the following vendor devices: Arista vEOS, Cumulus VX, Brocade Virtual ADX, Checkpoint GAiA, A10 vThunder, Alcatel 7750, NetScaler VPX, F5 BIG-IP LTM VE, MikroTik CHR, Juniper vMX and more....

All the complexity of connecting multiple emulators has been abstracted in what we call the controller (part of GNS3 server). From a user point of view, it means that it is possible to start a packet capture on any link, connect anything to a cloud etc. Finally, by using the NAT object in GNS3, connections to Internet work out of the box (note this is only available with the GNS3 VM or on Linux with libvirt installed).


Get started with GNS3 v2.0 now!




Save as you go

Your projects are automatically saved as you make changes to them, there is no need to press any save button anymore. An additional benefit is this will avoid synchronization issues between the emulators’ virtual disks and projects.


Multiple users can be connected to the same project

Multiple user can be connected to the same project and see each other changes in real time and collaborate. If you open a console to a router you will see the commands send by other users.


Smart packet capture

Now starting a packet capture is just as easy as clicking on a link and asking for new capture. GNS3 will guess the pick the best interface where to capture from. The packet capture dialog has also been redesigned to allow changing the name of the output file or to prevent automatically starting Wireshark:



Developers can find out how to control GNS3 using an API here: Thanks to our controller, it is no longer required to deal with multiple GNS3 servers since most of the information is available in the API. All the visual objects are exposed as SVG.


Key Videos on GNS3 v2.0


This video explains and demonstrates how to upgrade both the GNS3 Windows GUI and the GNS3 VM to version 2.0.0 of GNS3. This video uses Windows 10 for the demonstrations.



More helpful videos on GNS3 v2.0:


I’m pleased to announce three new releases are now available!


NPM 12.1


PerfStack TMMeraki Wireless Monitoring


All your IT metrics on a shared timeline.  >> Learn more


API based monitoring for your cloud managed wireless gear.  >> Learn more

Along with:

  • Mute alerts
  • Minor NetPath enhancements
  • Improved Arista 7500E support


Check out all the details in the release notes.  You can find NPM 12.1 now on the Customer Portal!



NCM 7.6


Firmware Upgrades


Leverage the power and simplicity of the new Firmware Upgrade Wizard to help

with all your Cisco IOS upgrades.  >> Learn more


Check out all the details in the release notes.  You can find NCM 7.6 now on the Customer Portal!



VNQM 4.4


  • Updated Cisco Call Manager Support (11.x)
  • Avaya Aura Communication Manager Support (6.3.x)
  • Web-based Alerting & Reporting


Check out all the details in the release notes.  You can find NPM VNQM 4.4 now on the Customer Portal!

Now that you’ve seen how to use PerfStack for networks, it’s time to check out the improved Meraki wireless monitoring of NPM 12.1!


This feature was born from a simple customer request: to cover Meraki gear in the same way we do all the other wireless vendors, showing their hybrid infrastructure in a single pane of glass.  Additional research show a common need: don’t develop some different monitoring specific to Meraki, just cover all my wireless gear in one spot, in the same way.


Now NPM has been able to monitor Meraki wireless gear for quite some time.  Use the Add Node wizard to add APs with SNMP polling, and you’re off the races.  But there were a couple of problems:

  1. Each AP had to be added individually.  Discovery can speed this up, but many users prefer not to run comprehensive discovery often. This really clashes with the idea that Meraki APs can be deployed with near zero touch.
  2. Client information is not available via SNMP, so it is missing in NPM.  Turns out client information is kind of important if you want to know what’s going on with your wireless service.


Essentially, these two issues crop up because of the unique and innovative way Meraki technology works. In traditional thin AP deployments, APs connect to a physical wireless controller that is on-prem.  The controller controls (obviously) the APs and provides a central spot for configuration and management.  Meraki compounds the benefit of the wireless controller by replacing the physical unit with a logical controller in the Meraki cloud.  This means you can express the wireless policy for all of your locations on Meraki’s dashboard, at virtually any scale.  You have one wireless configuration.  As new APs are added to the network, they can be deployed with virtually zero touch.  And you don’t have to manage any physical controllers.


Pretty slick.


How do you poll the cloud controller though?  SNMP really doesn’t make sense to use in a Meraki environment where the controller is logical, and you have to reach it over an insecure medium like the Internet.


The solution is to poll via API.  TLS protects the communication just like it does your credit card number when you make a purchase online.  And RESTful APIs are just a more modern, intelligent solution.


So we partnered with Meraki to get that done.  In NPM 12.1, you’ll notice a new option in the Add Node wizard:



Upon selecting Meraki Wireless: API, you’ll be prompted for your API key.  You can find this in your Meraki Dashboard.  Once that’s filled in, NPM will connect to the Meraki cloud and retrieve your Organization list.  Most companies will have a single Organization, but MSPs or companies that go through a lot of acquisitions may have multiple.  After selecting a specific organization and clicking next, NPM will discover all of the APs and list them just as we would for a traditional wireless controller.  You can select which you’d like to monitor, and additional APs can be monitored automatically.  With that done, you’ll see the Meraki logical controller, APs, and clients in your Node Details and Wireless views:




That’s it!  All the complexity happens on the backend, and the UI you use stays the same, just with more data.  Simple, right?


Some additional facts you may be interested:

  • Licensing works just like it does for traditional on-prem wireless controllers and thin APs.  The controller costs one node license.  The thin APs do not take licenses!
  • While NPM shows more metrics than before, we’re still missing a few things.  We’ll look to improve this as the data becomes available in the RESTful API.  And some data just doesn’t make sense for Meraki gear, for example Wireless Controller CPU and RAM.


We’re very excited to continue down this path of providing complete monitoring visibility of hybrid infrastructure.  Special thanks to Meraki for providing us with shiny new Meraki gear for our lab and working side by side with our development team.



NPM 12.1 is out, with Meraki wireless monitoring!  Check out the video to see how it works.  Current customers can find it in the Customer Portal.  If you don't own NPM and want to try it, or want to try it in a lab, you can get it here.


OK, OK, I admit it. My favorite new feature of NPM 12.1 is PerfStackTM which is actually a feature of the Orion® Platform (or “Core”). So my team didn’t actually build it. Darn.  Fortunately, all the products that run on the Orion Platform get it, including NPM.  More importantly, all products can contribute data to it, making it super powerful.


The idea is simple. Put all of the data points that Orion has on a single page and make it pleasantly interactive.  Check it out:




Search for an entity on the left, browse through all the data we have about that entity, and drag and drop it onto the visualization pane on the right.  Works for all sorts of different entities like nodes, interfaces, and volumes.  Works with all sorts of data types too, like status (think: up/down/warning), time-series (think: bandwidth utilization), and events (think: alerts).


What does that look like for networks?  Check it out:



Interface status, transmit utilization and errors, and top egress flows on a single page.  Including NPM and NTA data.  Awesome.  We’ve been wanting to build this into the product for years!  I never would have guessed we would instead build a framework so that YOU can build these views on a whim.


Making it this easy and fast to view data points is absolutely a game changer. I was exploring some of the data the other day.  It’s like the scientific method in real time.  Observe some data, come up with a hypothesis, drag on related data to prove or disprove your hypothesis, rinse and repeat.


Check this out.  We’ve been experiencing slowness on one of our routers here at SolarWinds.  Bandwidth wasn’t saturated, and slowness didn’t seem to be tied to any specific interface.  I started by seeing the performance the poller gets when contacting the router:




That looks good, so why is my transit traffic impacted?  How’s CPU and RAM?  Add those…



RAM is kinda high for a router.  Is that causing any buffer drops?  Yes! Let’s see what size is dropping by pulling in the history for the 5 different sizes.



Ok, so we’ve got high RAM, causing buffer misses, specifically and only for Medium Buffers. I can jump on the router and tell it to be more aggressive about preparing more Medium Buffers to cover spikes of packets of this specific size.


This takes literally seconds, which is exactly what you want during an outage.


And data is provided by everything that works on Orion Core.  Think about that!  Notice high load time on a web page?  Pull in your WPM chart to see the history.  Correlate to CPU usage.  Correlate that to IIS queues.  To interface stats.  To flow data.


PerfStack does several of the things you guys have been asking for, and a few extra things we thought up:

  • Imports new data points as they’re polled in near real-time.  Without reloading the page or even a graph.
  • Hide the metric panel if you want and PerfStack displays the graph full screen.
  • Save your favorite PerfStacks and go back to them whenever you want.
  • Send someone the URL of the PerfStack you’re looking at, and they’ll see the same, even without saving.  Of course if they don’t have permission to see some data, they’ll see only the data they have permission to see.
  • Update the timeframe and all charts will adhere to it.


Want to try it out for yourself?  Keep an eye on your inbox.  We’ll be emailing you soon that NPM 12.1 is ready in your customer portal!


And what would you do with PerfStack?  We want to hear over at the appropriately titled post: What Would You Do with PerfStack?

UPDATE: NPM 12 has landed! 


It took longer than usual to build this release but I can honestly say this is our biggest release in yearsNPM 12 is almost ready.



NetPath started as something we were fiddling with in the lab.  We came up with some really cool tech tidbits like:

  • Discovering the entire, complex path that connects users to services far, far away on the Internet.  Often dozens and sometimes hundreds of routers, links, and servers.
  • Quantifying the performance of every node and every link.
  • Correlating hop by hop performance on a node or link that is used for a portion of the traffic to the end-to-end performance experienced by users.
  • Determining what portion of latency is healthy and what portion is unhealthy.  That way, we can correctly mark a link between two routers in the same building as unhealthy when it takes 7ms and mark a transcontinental link that takes 30ms as healthy.
  • Reliably mimicking application traffic so we are allowed through firewalls and treated with QOS just like application traffic is.
Early NetPath.png

At the end of the day, tools should make problems easier to understand and solve.  As Network Engineers, we know there will never be a troubleshooting easy button, but our tools should always be aspiring to achieve that goal.Today, NetPath is our very best first attempt to reach toward that goal.  Today, NetPath looks like this:

NetPath Today.png

As NetPath strives to make network problems faster and easier to solve, we're super excited to see how it impacts your view of the network and how you solve network problems.



Network Insight for F5 BIG IP

Network Insight for F5 BIG IP provides deep, relationship aware monitoring of your F5 LTMs and GTMs (BIG-IP DNS). We get new metrics like concurrent connections by pool member and health monitor status. Most importantly, we are able to relate a single component to all of the dependent components. Or enumerate all of the components that must be working for a single service to work. is pretty important to us. We want to know fast if there is a problem, and what it is!


Network Insight for F5 Load Balancers - Mini Stack.png


UI Refresh

The UI for NPM and all other Orion based products has been refreshed. This includes two key changes.


First, we've rebuilt the top menu bar to minimize the space it uses, make navigation easier, and surface important features that are shared across several products, for example alerts and reports.

Menu Bar - Highlight.png


Second, we've reskinned the rest of the pages. This means colors and styles have been changed, but the function of the page is the same. Your cheese hasn't moved, it's just a different color! (hopefully that's good)

New UI Skin.png

The goal here is a clean UI that makes it easy to focus on things that really need your attention. This overhaul also provides a path to our truly next generation UI, the first of which can be seen in NetPath.


Improved Cisco Switch Stack Monitoring

Cisco switch stacks have a layer of technology beyond a simple fixed switch that allows the stack to act as a single logical entity. This release makes it easy to understand, monitor, alert, and troubleshoot on that layer of technology. NPM can:

  • List the member switches, and alert you upon membership changes.
  • Identify the master and backup master switches.
  • Discover CPU, RAM, and hardware health for each individual member.
  • Visualize the stack ring and identify partial failures.


Switch Stack - Highlight.png


And More!

ServiceNow integration, stackable poller scalability improvements, installation optimization, install pre-flight checks, built in upgrade path advisor, AD integration for discovery, auto-import from discoveries, and so much more. We can't wait to show you the rest! In the mean time, what looks most interesting to you?


Check out all the goodies in the Release Notes and get upgradedAnd be sure to check out the video at the NPM 12 microsite!

Since the release on NPM 11.5 we've been hard at working building the next round of exciting functionality and improvements in existing functionality.  I'm excited to share the following list of items we're working on:


Ongoing Initiatives:

  • Increased scalability per SolarWinds instance (target of 250k elements / instance)
  • Improved performance and decreased resource load times via analysis with SolarWinds DPA
  • Increased number of pollers possible per instance


You can always access the most up to date version of this information here: What We're Working on for NPM (Updated December 4th, 2017)


Disclaimer:  Comments given in this forum should not be interpreted as a commitment that SolarWinds will deliver any specific feature in any particular time frame. All discussions of future plans or product roadmaps are base on the product teams intentions, but those plans can change at any time.


NPM 11.5 Now Available

Posted by cobrien Employee Feb 24, 2015

It is my pleasure to announce the release of NPM 11.5!  This release includes:


Wireless Heat Maps


Capacity Forecasting


Web Based Alerting

Web Based Alerting.png

  • Wireless heat maps  with client location for Cisco controllers
  • Capacity forecasting for bandwidth, disk space, RAM, and CPU
  • Web based alerting
  • Automated dependency mapping to cut down alert noise and focus on the root cause
  • Mandatory custom properties to avoid provisioning oversight
  • Automatic geolocation on WorldMaps to translate SNMP location strings into a geographical view of your environment.
  • Automatically identify applications using the Packet Analysis Sensors and Quality of Experience dashboard
  • Enable, disable, or adjust hardware health monitors for individual nodes
  • Automatically identify new or rare devices in your environment based on SysOID.
  • Monitor interface state and display it on a timeline; no more combing logs for interface UP/DOWN!
  • Detect interface duplex mismatches throughout your environment like never before
  • More goodies for you to find!


We're confident these features will meaningfully increase your visibility and automate common tasks so you can get back to working on the interesting stuff.


The wait is over.  Get NPM 11.5 now on the Customer Portal!

It's 2014 and simple bandwidth saturation continues to be one of the most common network problems.  Every time we make advances in data transit rates, we seem to find new ways to use more bandwidth.  Or is it the other way around?  QoS helps us use the bandwidth we have more effectively, but adds a layer of complexity.  Another interesting side effect of QoS in many organizations is that, by successfully protecting critical application traffic, QoS allows you to defer bandwidth upgrades.  By the numbers, keeping your circuits saturated absolutely makes business sense.  Who wants to pay for bandwidth you don't use?  The strategy is so effective that saturated circuits are becoming the new normal.


When bandwidth saturation is the normal state and QoS is responsible for protecting our critical traffic, how do we monitor and troubleshoot slowness?  We no longer have an available bandwidth buffer that we can monitor as an indication of the health of the circuit and the quality of the service we're providing to all of the transit traffic.  Saturated circuits require a different strategy.


1-minute max to tell us about your IT troubleshooting pain points


Rummaging Through the Tool Box


Let's take a look in our tool box and see what makes sense to use with saturated circuits:

Ping - Ping falls in only one QoS category and it generally isn't the same category as your important traffic.  Accordingly, ping is not a very good indicator of health.

Bandwidth Utilization - High bandwidth utilization no longer means bad service.  In fact, arguably, high bandwidth utilization is exactly what you're trying to achieve.  This is also not a good indicator of health.

NTA - Knowing what different types of traffic make up your total traffic load continues to be important.  Knowing how much traffic is being sent or received within each QoS class and what types of traffic make up the contents of that QoS class are more important than ever.  Additionally, QoS queue monitoring provides a window into when QoS is making the decision to drop your traffic.

VNQM - VNQM uses IP SLA operations that can masquerade themselves as most other types of traffic.  You can monitoring how VOIP, SQL, HTTP, and other traffic are each uniquely serviced.

QoE - Where VNQM uses synthetic transactions (read: monitoring system generated) to constantly measure the service you're providing to a particular type of traffic, QoE watches your real transit traffic to see what kind of service you're actually providing your users.


Some of our older tools no longer have the fidelity and granularity we need to help.  Ping and simple bandwidth utilization are no longer good indicators of health.  We have to rely on more advanced testing tools like VNQM and QoE.  NTA remains our detailed view into what our traffic actually consists of, with a shift of importance to the QoS metrics.

It's interesting to me that QOE overlaps in some ways with NTA and in other ways with VNQM.  Like NTA, QOE can tell you about what traffic is traversing a specific link (using NPAS) or a specific device (SPAS).  NTA is much better at it than QOE though.  Like VNQM, QOE allows you to continually monitor the quality of service your network is providing but in a different way.  Where VNQM sends synthetic traffic and analyzes the results, QOE analyzes real end user traffic.  QOE's strong suit is providing visibility into the service level you're really providing to your end users and then breaking that down into network service time and application service time.

Now that we've reviewed our tools in this new light, let's look at how our monitoring and troubleshooting processes have changed.


Monitoring Saturated Circuits


Here's an example of how we traditionally monitored for slowness:

1) Ping across the circuit and watch for high latency.

2) Monitor interfaces and watch for high bandwidth utilization.

3) Setup flow exports so that when an issue occurs, you can understand the traffic.


When circuit saturation is expected or desirable, the steps change:

1a) Setup IP SLA operations to test network service at all times and/or

1b) Setup QoE to monitor real user traffic whenever it is occurring.

2) Setup flow exports so that when an issue occurs, you can understand the traffic.


One thing that is very important when all your circuits are full is to be able to ignore things that don't matter.  If bittorrent is running slow for your end users, do you care?  When all of your circuits are running hot, you need to be able to detect when critical applications are impacting your user's ability to do their job, and ignore the rest.


Troubleshooting Saturated Circuits


Here's an example of how we traditionally troubleshot network slowness:

1) Receive high latency alert, high bandwidth utilization alert, or user complaint.

2) Isolate slowness to a specific circuit by finding the high bandwidth interface in the transit path.

3) Analyse flow data to determine what new traffic is causing the congestion.

4) Find some way (nice or not nice) to stop the offending traffic.


When circuit saturation is the norm, troubleshooting looks more like this:

1) Receive alert for poor service from VNQM or QOE, or receive a user complaint.

2) Isolate slowness to a specific circuit by finding high bandwidth interfaces in the transit path and comparing which endpoints or IP SLA operations are experiencing the slowness.

3) Determine which QoS class to focus on by mapping the type of traffic affected to a specific QoS class.

4) Determine if the QoS class is being affected by competition from other traffic in the same class or in a higher priority class.

5) Analyze flow data within the offending QoS class to find the traffic causing the congestion.

6) Find some way (nice or not nice) to stop the offending traffic.


Your Thoughts?


Everyone has different tools in their toolbox and different environments necessitate different approaches.  What tools do you use to monitor and troubleshoot your saturated circuits?  What process works for your environment?


1-minute max to tell us about your IT troubleshooting pain points

Hello fellow network diagram geeks!  I'm excited to announce that NTM v2.2 beta1 is now available.  It has been quite some time since we've had a beta for NTM, but we're making some big changes and we need your input.


Let's take a look at what's new in this beta.


Modular Scanning


This is the big one!  We've fundamentally changed how scanning works in NTM.


What is Modular Scanning?

Since NTM's inception, one scan has resulted in one map.  To make multiple maps, you perform multiple scans.  Each map may contain any or all nodes found during the scan.  If you want to map a different part of your network, start over with a scan.  If you want to create a different view of the same network (L2 vs L3 diagrams anyone?), start over with a new scan.  Map getting too big and unwieldy?  Start over with a smaller scan.  This worked, but we think there's a better way.


In beta1, we introduce the concept of topology databases (shout out to you OSPF engineers out there!).  Now, when you perform a network scan, what you discover with NTM is saved in what we call a topology database.  You then build maps based upon the data in the topology database.  One map, 20 maps; however many maps you want.  All maps are stored in the topology database they're built from.  A single file on your hard drive contains a topology database and all maps built upon it.


This realignment of core functionality is simple to explain, but has had a big impact on how NTM works and how you interact with it.


How Does Modular Scanning Help Me?


Modular scanning lets you:

  • Scan once for your whole environment.
  • Build maps on the fly without performing new scans.
  • Flip between maps quickly because the maps are based on the same topology database.
  • Copy nodes (including their layout) between maps because the maps are based on the same topology database.
  • Keep your NTM diagrams updated with a single manual rescan or rescan schedule.
  • Spend more of your time making useful maps and less of your time configuring, scheduling, and waiting on scans.


In addition, the rendering changes (described in the next section) that were required to deliver modular scanning properly provide the following additional benefits:

  • NTM's is faster and scales better in medium and large environments.  Try it.
  • Auto Arrange functions tend to produce more appropriate icon layouts without so much extra space.


Rendering Change

When we started down this path, we knew we would also have to significantly change how we render nodes.  In previous versions of NTM, filters were used to control whether nodes would display or not.  Enabling filters or disabling filters does not give NTM any indication of where you would actually like to place those nodes.  As a result, whether you were displaying all of your discovered nodes or 5% of your discovered nodes, NTM always kept track of every node and where it was on the screen to prevent the nodes from overlapping.  Although there were some benefits to this, there were two big negative effects:

  • Displaying maps where many nodes were discovered took more compute resources than was necessary.  Maps with many discovered nodes could be slow or laggy feeling, even if only a handful of nodes were actually visible.
  • When many nodes were hidden, the Auto Arrangement functions would often separate node icons by huge amounts of distance to make room for nodes that were hidden in between the visible nodes.


We knew modular maps will  naturally result in users doing bigger scans.  The performance issues and layout issues noted above would cause severe problems at that scale.


So we fixed them.  NTM now only renders nodes that are actually on the map.  All nodes exist in the topology database.  You place nodes onto your map by dragging and dropping from the left hand pane (ala Network Atlas), and the nodes that you don't want to see don't bog you down or cause rendering oddities.


While NTM's scalability and performance used to revolve around the total number of discovered nodes regardless of how many nodes were displayed, it now revolves around how many nodes are displayed on the map you're looking at.

Filters.pngDrag and Drop.png

Icons, Icons, Icons!


You want better icons, bigger icons, smaller icons, custom icons, icon alignment, icon spacing, and anything else icon related we're willing to build.  We've heard you.  Let's see how much of this functionality we can show in one screenshot:




  1. All new out of the box icons in a scalable format
  2. Re-sizable icons
  3. Custom icon import
  4. Icon alignment tools
  5. Even icon spacing tools
  6. Text alignment
  7. Arbitrary text placement.

Best of all, you can do all of these with bulk operations.



Enhanced Etherchannel Support


This wouldn't be an NTM release if it didn't improve NTM's ability to map your network.  This beta now does a much better job of discovering and mapping your Etherchannels, port-channels, or whatever you choose to call your L2 aggregated links.  Take a look:




  1. Accurately detecting Etherchannel
  2. Rendering member links of Etherchannel as parallel
  3. Excluding links that are not part of Etherchannel, even if they are parallel
  4. Identifying port-channel name
  5. Protocol name
  6. Protocol mode
  7. Aggregate bandwidth


So Much More


In addition to the big items above, we've made a truck load of other smaller improvements.  Here's some of them:


  • Not sure what connects to the nodes on your map?  Try right clicking and selecting "Add Neighbors".
  • How do you interact with multiple topology databases at the same time?  A drop down in the application?  Multiple levels of tabs?  Yuck.  In this beta, for the first time, you can open multiple instances of NTM.
    • Each NTM instance holds all the maps for one topology database.
    • If you have two topology databases open, you can scan in one window and continue working in the other.
    • If you have three topology databases open, you can scan in two windows (parallel scanning) and continue working in the remaining one.
  • Shortcuts allow you to add intelligent groupings of nodes to your map all at once.
  • Select nodes in the map you're looking at intelligently by clicking on individual nodes, groups of nodes, or node shortcuts in the left hand pane.  For example, selecting the "Router" group in the left hand pane selects all routers on your current map.
  • Connection jumps.
  • Copy paste nodes or groups of nodes between your maps.  Layout is preserved.
  • Improved Credential Management UI.
  • Extensible regex interface name handler to intelligently shorten interface names so they fit well on the map.



Known Issues in This Beta


  • Undo/Redo buttons sometimes do not work.
  • Etherchannels that are configured statically (mode "ON") are not currently detected as Etherchannels.




We're very excited about this release and can't wait to see the maps you guys create.  Feel free to post your feedback or your new maps in the NTM Beta Forum or email me directly at chris.obrien{at}




As a reminder, beta software is for testing only and should not be used in a production environment.

There is a lot more NTM could do and that I want it to do.  If we go and build those things we have to raise the price though.  I don't want to raise the price.  There are already options for people that want to do very careful, very manual map creation at a cost of free or effectively free.  There are also options for people that want very advanced automated map creation at a premium price, something like 10x to 30x more expensive than NTM.  I believe NTM is unique in offering a mostly automated solution at a super affordable price and I believe that's the best fit for most of our customers.


We will continue to build features as we see the need, but I want to set correct expectations that we do not expect frequent major updates.  We will continue to provide 24/7 support, hot fixes, and so on as we have always done for NTM.


Have an idea?  We'd love to hear about it!  Add it here: Network Topology Mapper Feature Requests


PLEASE NOTE:  We are working on these items based on this priority order, but this is NOT a commitment that all of these enhancements will make the next release.  We are working on a number of other smaller features in parallel.   If you have comments or questions on any of these items (e.g. how would it work?) or would like to be included in a preview demo, please let us know!

The time has come for yet another Log & Event Manager (LEM) Release Candidate! The RC is already available on the Customer Portal for all LEM customers under maintenance. Release Candidates can be deployed in production and are fully supported by our awesome support team. Read on to find out what new features you can play with in this RC!


File Integrity Monitoring for Windows


File Integrity Monitoring, or FIM, tracks events that occur in the file system.  There are many events that occur in the file system, but most likely you're interested in things like file creates, reads, writes, deletes, permissions changes, and so on.  As with all data sources in LEM, FIM is a connector.  To get FIM up and working, click Manage > Nodes, click the gear next to your node, and hit Connectors.  There you'll see the two new FIM connectors:

FIM Connectors.png

We'll come back to the registry connector in a minute.  Adding a new FIM File and Directory connector brings you into the first FIM configuration screen:

FIM File and Directory Monitors.png

From here you can apply one of our bundled templates as you can see on the left, or create your own custom monitors.  Custom monitors allow you to create sets of conditions, with each condition containing granular configuration of exactly what file system events you're interested in monitoring:

FIM File and Directory Conditions.pngFIM File and Directory Add Condition.png

LEM lets you browse the file system of your remote node right from the manager UI making it that much easier to specify directories:

FIM File and Directory Remote Browse.png

FIM makes full use of templates.  You can use ours, add to ours, create your own, share between administrators, and so on.  We've also extended this FIM logic to the Windows registry.  Take a look:

FIM Registry.png

You can find FIM documentation on pages 38 and 268 to 274 of the User Guide.

In LEM, FIM becomes yet another source of data that you can log, analyze, and take action upon.  With correlation rules, the more information sources you have the more accurate and decisive your alerts and other automatic responses can be.


And a Few More Things


FIM is the main feature in this RC, but we've done a few other things too:

  • Significant performance improvements for specific types of rules.  Rules that contain either the AND and OR subgroups or the various system look up groups (User Defined Groups, Connector Profiles Groups, Directory Service Groups and/or Time Of Day Sets) may run faster with less RAM and CPU usage.
  • New connectors for LOGbinder EX, Cisco®, VMware® and more.
  • Various bug fixes.

Questions, Issues, Comments - Send 'em Our Way

Feel free to use the Log & Event Manager Release Candidate Thwack forum to report and comment on any issues, questions, or comments you have about this release. Our product management, development, and QA teams are keeping an eye out for any possible issues.

If you have a question about whether a case you've filed was resolved in this release or a certain feature request implemented, feel free to ping back on this post or in the RC forum and let me know - I'll be sure to look into it.

Happy Logging!

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.