Skip navigation

Product Blog

11 Posts authored by: cobrien Employee

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!

 

NEW FEATURES DETAILS

 

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:

NEW API

 

Developers can find out how to control GNS3 using an API here: http://api.gns3.net/en/2.0/ 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

1.png

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

2.png

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

3.png

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:

1.png

 

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:

2.png

 

 

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.

 

Edit:

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.

download.jpeg

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:

 

1.png

 

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:

2.png

 

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:

3.png

 

 

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

4.png

 

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.

5.png

 

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

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. www.solarwinds.com 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 March 17th, 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.

cobrien

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

WLHM.png

Capacity Forecasting

Capacity.png

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.

button.png


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:

 

2014-10-08_18-45-25.png

 


  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:


Etherchannel.png

 

 

  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.

 

Conclusion

 

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}solarwinds.com

 

button.png

 

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: