Just a starting point to discuss what is working and not working with your Network Discovery.

sjasurfertommesverrumDezrschroeder

Does anybody know the minimum  IPAM Roles & Permissions for the user that VRO would use for this? Currently I have it set to power user but this doesn't seem to work.

Thanks Jeff

Those that have been part of the Thwack Community a while may be familiar with the long running Tell us your "Unknown" devices! thread which had been active since 2007. That thread had become too unwieldy, and most of the user submissions had been implemented many years ago. I recently reviewed each and every posting in that thread, verified what had been implemented in-product, and which ones had not so they could be included in a forthcoming release. With that done, it was time to lock that thread for good and start anew. This time, providing a bit more guidance along the way to ensure everyone is successful in providing the necessary information required to properly identify these devices.

What is an 'Unknown' Device anyway?

Orion does its best to automatically identify and classify nodes as they're added to Orion. There are however, new device types and models released all the time. It's entirely possible you might be managing a device right now that Orion is unable to properly identify. You can find these easily by going to [Settings - Manage Nodes], changing the 'Group by:' option to 'Machine Type' and clicking on the 'Unknown' category. It's also helpful to add the 'Polling Method' column to the layout, as this thread pertains exclusively to SNMP managed nodes.

Any SNMP managed nodes listed under the 'Unknown' Machine Type category are prime candidates for submission to this thread. All that's required is that you provide the devices SNMP System Object Identifier (SysObjectID), as well as the Make & Model of the device associated with that SysObjectID. This post is an excellent example of the perfect submission.

What Exactly is a SysObjectID?

I have yet to find a clearer definition for what the SysObjectID (System Object Identifier) is then the following excerpt which can typically be found written in virtually every vendor's MIB file verbatim.

Object Name: sysObjectID
Object ID: 1.3.6.1.2.1.1.2.0
Object Syntax: OBJECT IDENTIFIER
Object Access: read-only
Object Status: mandatory
Object Description: The vendor's authoritative identification of the  network management subsystem contained in the  entity. This value is allocated within the SMI  enterprises subtree (1.3.6.1.4.1) and provides an  easy and unambiguous means for determining `what  kind of box' is being managed. For example, if  vendor `Flintstones, Inc.' was assigned the  subtree 1.3.6.1.4.1.4242, it could assign the  identifier 1.3.6.1.4.1.4242.1.1 to its `Fred  Router'.

Essentially, it's a string of numbers in dotted notation that is (hopefully) unique to at least the manufacturer, and in most cases, to the specific make and model of the device being monitored. It's how we identify for example, that the device vendor is 'Cisco' and the model is a 'Nexus C7018'. All System Object ID's begin with '1.3.6.1.4.1' followed by a number which uniquely identifies the manufacturer. The numbers which then follow typically identify the specific model of the device.

Where Can I Locate the SysObjectID?

If the device is already managed as a Node in Orion then you can locate the SysObjectID in the 'Node Details' resource as shown below, when viewing the node in the Orion web interface.

Node Details

NET-SNMP

Alternatively, you can use NET-SNMP to query the following SNMP OID to return the unique SysObjectID.   1.3.6.1.2.1.1.2.0   Below is an example of the 'snmpget' command line arguments which will return you the SysObjectID for the device.   snmpget -v2c -On -c public 10.199.5.103 1.3.6.1.2.1.1.2.0   The example above is executed against a device with the IP address of '10.199.5.103' using SNMPv2c, with the community string 'public'. Below is a screenshot of the resulting output from that command. The string of numbers and periods highlighted in yellow below is this device's unique SysObjectID.

My Device Incorrectly Appears Listed as 'NET-SNMP'

Linux hosts, virtual appliances, and even some network equipment built on Linux, FreeBSD, etc. are often identified as 'NET-SNMP'. This is because the SNMP Daemon running on those hosts is, you guessed it, NET-SNMP. Unfortunately, these vendors for some reason, have chosen not to implement their own unique SysObjectID, and instead kept the default SysObjectID '1.3.6.1.4.1.8072.3.2.10' which is designated for NET-SNMP. If you have a device such as this, fret not. There are a few options available to you if you'd like these devices to be properly identified by their appropriate vendor's make & model within Orion.

Install The Orion Linux Agent

The easiest solution would be to install the Orion Linux Agent on the device which is reporting itself to be 'NET-SNMP'. The Linux Agent does not rely upon SNMP to identify the machine type or vendor. Instead, the Agent will report the Vendor as 'Linux' and the 'Machine Type' as the Linux distribution running on the device as depicted in the screenshots below.

Red Hat	Citrix XenServer

Modify NET-SNMP Configuration

Another approach is to customize NET-SNMP and Orion to properly reflect the Vendor and Machine Type. Simply following the steps outlined by adatole's post entitled No More Net-SNMP Nodes. This method uses a script osname.sh which is executed when a particular OID is is queried. Next, you would create a custom Device Poller to query that newly created OID and populate the Machine Type value in Orion for that device.

If you find it more fun to follow along, you can watch adatole walk you through the entire process in the following video.

Can't I Just Upload My Vendor's MIB File Here And You figure it Out?

While it would be nice if that's how it worked, unfortunately many (or most) vendors don't include this information within their MIB files. MIB files include a listing of all possible OIDs which could be polled across a wide variety of different devices (typically an entire product family), but it doesn't include the values which are returned by the devices (Enums notwithstanding). For that reason we need users, such as yourself, to post the SysObjectID's in this thread, along with the device vendor and model information so it can be included in our database.

If you'd still like your device's MIB file included in the Orion MIB database, for use with Network Performance Monitor's Universal Device Poller, or the Orion Platform's SNMP Trap Receiver, simply follow the steps outlined in KB article at the link below.  The latest version of the MIB database, containing your submissions, can always be downloaded from within the Customer Portal.

Request additional MIBs to the SNMP MIB browser database - SolarWinds Worldwide, LLC. Help and Support

Hi All,

Is Monitoring of devices having IPV6 addresses supported in Solarwinds? I did go through couple of KBs and it mentioned module wise details but wanted to cross verify if there is specific settings required for this to be made possible. By settings i refer to both-> Device end and Solarwinds end.

Also is there any limitation of monitoring devices having IPV6 addresses?

Hi,

I have around 200 sites added in Solarwinds, each side having specific number of nodes in it. example Site A has 10 nodes, Site B has 20 nodes etc. I have request where I want to show top XX CPU per site.I tried creating it through Custom table in Reports type but it shows overall Top xx and not per site basis. Is there any way I can achieve this? Please help.

I'm in the process of converting a few of our alert emails and I'm wondering if there is an easy way to do what I'm aiming to accomplish.

If a group goes down, for X number of minute an alert email is fired with some basic information such as time, link to group on Orion etc. On other network monitoring software I've used it's always been possible to include a chart of some description into the alert email such as a utilization chart on a utilization alert and so on. So I'm trying to do something a bit similar. I've had some limited success so far and can quite easily insert a chart into the body of the email for the whole day by doing the following

/Chart.aspx?ChartName=ContainerAvailability&NetObject=C:${GroupID}&Period=${MM}/${DD}/${YYYY} 0:00 AM~${MM}/${DD}/${YYYY} 11:59:00 PM&SampleSize=1M&ShowTrend=False&Width=640

However I'm having difficulty finding a way to do the same thing for different time frames such as a 7 day chart. Is there any way to manipulate the returned values of variables so that a date returning 14 can become 7, or a time of 11:00 can become 10:00?

Or maybe I'm doing things in an overly complicated way and have completely missed something. Wouldn't be the first time!

Hello I'm very newbie on SolarWinds.

I want to know about , what information can provide by NPM+NTA and if I have only NPM what information I can't no longer see in NPM+NTA.

Thank you.

Using 12.2 Latest HF and the performance is horrible in the UI. I use many enterprise apps with web front ends that handle lots of nodes/data and they seems to be able to render much more quickly than seemly trivial pages in NPM. For example, the 'All settings' page regularly takes 3-5 seconds to load. This is slow as it should be just text based html. I've been looking at it with chrome dev tools and lighthouse and its seems the Javascript and general caching is not optimized at all, For example, this near 1 MB javascript library seems to be being repeatedly downloaded:

• http://mynpm/ui/scripts/apolloisolate?43201.41.L

This also has the header no-cache on it.

I've a support ticket open and its been indicated to me that this is a known issue.

Hello,

I recently deployed HA in our customers environment which went well and successfully created pool.

We changed the IP address of our standalone Main poller to a new IP and assigned the old IP as a VIP to avoid configuring network devices with a new SNMP hosts.

When we failover to Standby server, it was observed that few nodes appears as down(while they are actually UP) and comes UP when we failback to Primary server.

Has anyone faced similar issue?

Talking about the choice of source IP address between VIP and polling engine IP for SNMP polling, the matching bits to default gateway are same(25 bits). So, int this case, what will be the source IP? Either VIP or polling engine IP?

Hi

What could be the reason SolarWinds does not allow user to change their own credential?

/MSARKAR

Hi Everyone,

I'm planning to deploy another NPM instance, wondering which has more benefits between AWS versus the Local premises. The additional instance will for Dev only use only. Expert opinion will be very much appreciated.

As aLTeReGo mentioned in Orion Platform 2018.2 Improvements - Chapter One , we have lots of exciting things packed into this release.  It is my pleasure to present to you, the first step in the next generation of Orion mapping.  Now let me begin by prefacing that this is a MASSIVE project.  The functionality that you see here is an iteration of a new generation of mapping technology, and is not intended to be feature by feature replacement of any of our tools that provide mapping functionality today, for example, Network Atlas.  Our goal as we take on this endeavor is to find methods for building upon our dream of one mapping tool to rule them all, but provide you significant chunks of value along the way.  We need to first build the framework to accomplish this goal, yet we don't want to hold back something you may find useful in the interim.

Intelligent Mapping - What is it?

As environments grow in complexity, identifying a problem's root cause and impact tends to be just as complex.  Many of you are looking for a more intuitive way to aggregate and visualize that data in a simple manner that is meaningful for your environment.  A function such as intelligent mapping in a monitoring tool can help alleviate much of the pain derived from combing through pages of data, and reviewing the details provided through individual resources piece by piece.  Understanding your needs and the problems you are trying to solve is fundamental in everything we do.  A major theme that emerged from our community is that everyone loves the idea of maps and sleek visualizations, the problem was, maintaining them.  Spending time in Network Atlas can yield some significant results, but time is not a luxury that many of us have.  If something changes, which it does constantly, you are forced to set aside more time to go mimic those changes in the map.  This presents and interesting challenge for SolarWinds, but also gave us a potential entry point....

With this project, we needed to first conceptualize what will be needed across all iterations, and where our starting point should be.  As alluded to before, tons of functionality exists today in tools like Network Atlas, the WorldMaps widget, and even through AppStack, that allow users to "visualize" their environments.  While these tools all have their unique capabilities inside the platform, we want to begin down the path of advancing those capabilities even further, and allow the power of the platform to shine.

The first step that needed to be taken was to obviously visualize the entities within Orion.  When I say entities, I am referring to any object monitored by Orion such as network devices, servers, interfaces, volumes, and so on...  The second similarly important factor is that we needed to visualize the connections between those entities.  Whether these connections are based on physical or logical relationships, this data is just as critical to quickly reflecting points of concern in your environment.

Orion Intelligent Mapping is an advanced troubleshooting tool that provides a contextual and graphical portrayal of an entity and its critical relationships.  In other words, this functionality will be available out-of-the-box for entities like your routers, switches, servers, interfaces, volumes, and even groups.  It visualizes the physical and logical relationships between them, leveraging data from Network Performance Monitor's Topology, Server & Application Monitor's Application Dependencies, and other relationship information, to quickly isolate and identify critical health and performance issues.

In this version, maps are made available by drilling into an entity details page as shown below.  What this means, is that when you upgrade to any product containing the 2018.2 Core, and drill into an entity details page, there will be a sub-view that is provided for you called "Map".  Clicking on that view will obviously generate... wait for it... a map!

Our number one goal was that maps require absolutely no user intervention, and are updated automatically as changes are made in the Orion environment.  The list of entities that are supported for this version are as follows: Nodes, Interfaces, Volumes, Virtual Machine, Virtual Host, Virtual Clusters, Virtual Datacenter, VCenter, Hyper-V Hosts, Hyper-V Cluster, WPM Step, WPM Transaction, WPM Player Location, and Groups.

Map Canvas

There are two key components to this feature.  The section that contains the visualization and the actual graph is what we refer to as the canvas.  In the example provided, selecting an entity's map view pulls up a detailed graphical representation, with the map centered on the "seed" object (see Figure 1).  Everything else drawn on the map, stems from that seed.  Anything not immediately connected to the seed entity is opaqued in order to differentiate and provide a point of focus.  This comes in especially handy with larger maps that could have excessive elements on them.  The goal here is to draw attention to problems associated to the entity you are investigating, but also extend that investigation to related connections or neighboring devices(Figure 2).

Figure 1	Figure 2

We needed to incorporate some creative design strategies as well.  For example, at times there may be multiple connections between two entities.  Whether those represent a simple relationship or actual data flow, we have to be conscious of the way that data is represented in the map.  Too much data, and the map becomes unusable.  Too little, and it doesn't really prove to be the powerful troubleshooting aid intended.  Any entity or connection that has breached a threshold will be automatically surfaced in the context of the map.  This way you are not sifting through data to identify areas of concern.

This is also the area that allows you to interact with the map through controls such as zoom and pan options.  You may also target specific areas of the map through hovering, or selecting a device or connection.  In the bottom right hand corner, we do provide controls so that you can toggle layouts, click to zoom in or zoom out, center the map on a selected entity, or even launch into full screen mode to have as much real estate as possible for viewing the map.

The Inspector Panel

The second core component of the map is what we refer to as the inspector panel.  The inspector panel is like a mini data warehouse for the entities and connections on the map.  In this version, selecting an entity such as a node will pop open the inspector panel from the right, which will show the name of the device, IP, Vendor, and Machine Type, along with a list of all that entity's "children" or "decedents".  The list generated will be in context to the entity selected.  For example, a server may have interfaces, volumes, and applications that would be considered children/decedent's of this node.  If drilling into the application however, its children or decedents would be the components that make up that application.  This list has controls such as "Sort" that allows you to control ascending and descending formatting of the list either via status or name, and "Show" which provides filters based on entity type such as hardware or interface.  We also provide a "type ahead" search feature for those long lists that extend beyond a single view-able page.

Selecting a connection between entities on the canvas will provide you an inherently different view of the inspector panel.  As previously mentioned, there are obviously multiple types of connections which could be represented and we need to ensure this is easily interpreted through our tool.  In order to provide you the ability to distinguish between these distinct types of connections, we have managed to include unique behavior for each connection type.  The following connection types will be visible in the map sub-view.

Orion Dependency Connection

The dependency connections do not represent any kind of data traversing between the two entities, but rather easily convey that a relationship exists between them.  It could be an administratively defined dependency, or perhaps a dependency identified through its ancestry.  In the screenshot below I selected a virtual machine, and can see this VM has a relationship to its host, which has a relationship to its cluster, to the datacenter, and the finally, the VCenter.

The inspector panel view of these connections would look as follows:

Application Dependency Connection

For those of you unfamiliar with the ADM Connections, this was a feature introduced in Server & Application Monitor 6.6 which allows you to quickly see which applications or systems are communicating to each other.  You can learn more about that feature here Announcing General Availability of Server & Application (SAM) 6.6.  Since Orion Maps is a feature of the platform, we don't want to leave anyone out, so of course this type of communication is captured and also mapped automatically as a distinct connection type.  There are two possible visualizations you may notice depending on how you adjusted Application Connection Settings.  With Connection Quality Polling enabled, the connections will highlight additional data pertaining to TCP latency and packet loss between the two entities.

Selecting an ADM Connection will provide a list of the processes communicating between the two systems and allow for additional detail by drilling into the Connection Details page.

If you have not enabled Connection Quality polling, we will represent the relationship on the canvas by a light blue line with no metric pill.  This connection is still automatically identified, and therefore mapped within the canvas.  You will also have access to the Connection Details page.

Topology Connection

Topology Connections are generated through NPM's topology engine and meant to provide a unique representation of your network infrastructure.  Emanating from community feedback, the design illustrates how a ton of detail can be depicted in a single, simple connection, and even has a Network Weather-map type feel.  First, the width of the topology connections will be based on interface bandwidth.  This means whether you have a 10 GB link, a 1 GB link, or a 100 Mb link, you should easily be able to determine differences across the map.  This is useful for quickly identifying if bandwidth is properly set and distributed across the environment.  Hovering over a topology connection will provide a tool-tip for the metric pills similar to what you see in the screenshot.

By default, the metric pills highlight outbound traffic and utilization details on either side of the connection.  Based on thresholds set in NPM, these links will change to yellow for warning, or red to critical, if a threshold is breached.  The link may also change to highlight something else entirely.  Below you can see a specific interface which has hit a critical threshold for errors & discards.

The inspector panel will contain all the connections between two entities.  In the example below, the map is surfacing the problem link and indicating a threshold has been met, while the inspector panel displays all the data between each connection.  On either side of the panel will be the interfaces, which can be associated to the parent device situated above.  In an easy to read table, all the most recent polled data for traffic, errors & discards, utilization, and the maximum bandwidth will be presented.

Maps in Groups

The new map sub-view is also automatically generated within groups.  Groups are treated as an entity just like an interface, volume, node, or any other object in Orion.  However, behavior of maps within groups is slightly different.  When creating groups, you are specifying particular members that are the focus for that group.  In this context, we don't want to show "related" entities on a group map, or conversely roll entities up to a parent, if that was not your overall intent.  Therefore, drilling into a map sub-view for a group will show group members only and any connections that exist between the member objects in the group.  This allows a bit of control in this version, as here you have the opportunity to decide what objects are included in a map.  Many of you may already leverage groups today in unique ways, and this could provide some additional visibility for those views.  The great thing is that you could leverage dynamic queries to speed up the building of groups, which will then auto-add new members to the map.  This means there is little to no maintenance for the maps being built through this process.  Guess I am going to have to retire my post for how to do this today:  Custom Maps for Group Details Page

Here is an example in which I mapped out the entire virtual infrastructure in my lab.

We are excited to take this step and anxious to hear your feedback.  We feel that this tool will allow you to see massive amounts of data in a single comprehensive view, and mitigate having to jump from page to page to isolate problems.  The best part is that you don't have to do anything!  We hope to continue to build on this within the platform as we have a very long list of feature requests from our community, and I promise we are listening.  Stay tuned for more.  serena still has more great things from the platform in her post:  Orion Platform 2018.2 Improvements - Chapter Three

I am very excited to announce a NEW VERSION of ORION MAPS:  Orion Platform Improvements - Intelligent Mapping Enhancements

Those that have been part of the Thwack Community a while may be familiar with the long running Tell us your "Unknown" devices! thread which had been active since 2007. That thread had become too unwieldy, and most of the user submissions had been implemented many years ago. I recently reviewed each and every posting in that thread, verified what had been implemented in-product, and which ones had not so they could be included in a forthcoming release. With that done, it was time to lock that thread for good and start anew. This time, providing a bit more guidance along the way to ensure everyone is successful in providing the necessary information required to properly identify these devices.

What is an 'Unknown' Device anyway?

Orion does its best to automatically identify and classify nodes as they're added to Orion. There are however, new device types and models released all the time. It's entirely possible you might be managing a device right now that Orion is unable to properly identify. You can find these easily by going to [Settings - Manage Nodes], changing the 'Group by:' option to 'Machine Type' and clicking on the 'Unknown' category. It's also helpful to add the 'Polling Method' column to the layout, as this thread pertains exclusively to SNMP managed nodes.

Any SNMP managed nodes listed under the 'Unknown' Machine Type category are prime candidates for submission to this thread. All that's required is that you provide the devices SNMP System Object Identifier (SysObjectID), as well as the Make & Model of the device associated with that SysObjectID. This post is an excellent example of the perfect submission.

What Exactly is a SysObjectID?

I have yet to find a clearer definition for what the SysObjectID (System Object Identifier) is then the following excerpt which can typically be found written in virtually every vendor's MIB file verbatim.

Object Name: sysObjectID
Object ID: 1.3.6.1.2.1.1.2.0
Object Syntax: OBJECT IDENTIFIER
Object Access: read-only
Object Status: mandatory
Object Description: The vendor's authoritative identification of the  network management subsystem contained in the  entity. This value is allocated within the SMI  enterprises subtree (1.3.6.1.4.1) and provides an  easy and unambiguous means for determining `what  kind of box' is being managed. For example, if  vendor `Flintstones, Inc.' was assigned the  subtree 1.3.6.1.4.1.4242, it could assign the  identifier 1.3.6.1.4.1.4242.1.1 to its `Fred  Router'.

Essentially, it's a string of numbers in dotted notation that is (hopefully) unique to at least the manufacturer, and in most cases, to the specific make and model of the device being monitored. It's how we identify for example, that the device vendor is 'Cisco' and the model is a 'Nexus C7018'. All System Object ID's begin with '1.3.6.1.4.1' followed by a number which uniquely identifies the manufacturer. The numbers which then follow typically identify the specific model of the device.

Where Can I Locate the SysObjectID?

If the device is already managed as a Node in Orion then you can locate the SysObjectID in the 'Node Details' resource as shown below, when viewing the node in the Orion web interface.

Node Details

NET-SNMP

Alternatively, you can use NET-SNMP to query the following SNMP OID to return the unique SysObjectID.   1.3.6.1.2.1.1.2.0   Below is an example of the 'snmpget' command line arguments which will return you the SysObjectID for the device.   snmpget -v2c -On -c public 10.199.5.103 1.3.6.1.2.1.1.2.0   The example above is executed against a device with the IP address of '10.199.5.103' using SNMPv2c, with the community string 'public'. Below is a screenshot of the resulting output from that command. The string of numbers and periods highlighted in yellow below is this device's unique SysObjectID.

My Device Incorrectly Appears Listed as 'NET-SNMP'

Linux hosts, virtual appliances, and even some network equipment built on Linux, FreeBSD, etc. are often identified as 'NET-SNMP'. This is because the SNMP Daemon running on those hosts is, you guessed it, NET-SNMP. Unfortunately, these vendors for some reason, have chosen not to implement their own unique SysObjectID, and instead kept the default SysObjectID '1.3.6.1.4.1.8072.3.2.10' which is designated for NET-SNMP. If you have a device such as this, fret not. There are a few options available to you if you'd like these devices to be properly identified by their appropriate vendor's make & model within Orion.

Install The Orion Linux Agent

The easiest solution would be to install the Orion Linux Agent on the device which is reporting itself to be 'NET-SNMP'. The Linux Agent does not rely upon SNMP to identify the machine type or vendor. Instead, the Agent will report the Vendor as 'Linux' and the 'Machine Type' as the Linux distribution running on the device as depicted in the screenshots below.

Red Hat	Citrix XenServer

Modify NET-SNMP Configuration

Another approach is to customize NET-SNMP and Orion to properly reflect the Vendor and Machine Type. Simply following the steps outlined by adatole's post entitled No More Net-SNMP Nodes. This method uses a script osname.sh which is executed when a particular OID is is queried. Next, you would create a custom Device Poller to query that newly created OID and populate the Machine Type value in Orion for that device.

If you find it more fun to follow along, you can watch adatole walk you through the entire process in the following video.

Can't I Just Upload My Vendor's MIB File Here And You figure it Out?

While it would be nice if that's how it worked, unfortunately many (or most) vendors don't include this information within their MIB files. MIB files include a listing of all possible OIDs which could be polled across a wide variety of different devices (typically an entire product family), but it doesn't include the values which are returned by the devices (Enums notwithstanding). For that reason we need users, such as yourself, to post the SysObjectID's in this thread, along with the device vendor and model information so it can be included in our database.

If you'd still like your device's MIB file included in the Orion MIB database, for use with Network Performance Monitor's Universal Device Poller, or the Orion Platform's SNMP Trap Receiver, simply follow the steps outlined in KB article at the link below.  The latest version of the MIB database, containing your submissions, can always be downloaded from within the Customer Portal.

Request additional MIBs to the SNMP MIB browser database - SolarWinds Worldwide, LLC. Help and Support

I think, it has been a request to all who manage Solarwinds Monitoring. Each tower would like to know the parameters enabled for monitoring of their devices/servers. I don't think we can get them in a single report.

When it comes to all parameters enabled for monitoring, shold include the List of Resources enabled (only) and components enabled via Application Templates and any otherway enabled for monitoring along with their threshold values (if exists).

Need a report for device, what are all the parameters Solarwinds can monitor and all the monitoring parameters enabled and not enabled. Need help, to provide the report, because, it is a daily request from different teams now-a-days.

adatole, aLTeReGo, Geek Speak, CourtesyIT<-- Including Geeks and experts to get an answer.

Hi!

Is it possible using sonar discovery using ICMP only? Because when I use it, not all nodes are seen. But when I manually add IP Addresses/nodes using ICMP only, they appear and get registered as nodes, although in ICMP mode only. But this is temporary since the network is still being fixed to accept SNMP.

TIA.

We are in the process of looking at purchasing a large TV to use for our NOC display. Does anyone have any suggestions on software that will allow us to split the display into multiple displays/desktops to monitor not only NPM NOC tabs but other 3rd party applications as well?

We have configured solarwinds to audit config changes and login/out.  This data goes into the AuditingEvents table.

In looking for how to get SW data into Splunk, I found two ways - setup a DB Connect SQL connection and query, or use a Splunk Add-on (https://splunkbase.splunk.com/app/3584/)

The latter is setup to import three things:  the list of nodes, all alerts, and the output of a 'custom query' - for which we would query the AuditingEvents table  (as an aside, I don't understand why the add-on was written to ignore audit-able events without doing custom work)

We decided to use DB Connect since it was just a simple query to get what we need (and no messing around with disabling components of the Add-on).  And then we went in circles for the rest of the day, thinking it was problems with SQL or similar.  It turns out the splunk DB Connect feature is glitchy, giving random time-out and (fake) permission denied messages even when permissions up to dbo were set.

For obvious reasons I think we will go back to using the Add-on.

What have other people used?

This is the basic query we wrapped into a view to use (we also found that a stored procedure could not be used, as any command is wrapped in  "SELECT * FROM (   )" )

select AuditEventID, TimeLoggedUTC, AccountID, typ.ActionTypeDisplayName, AuditEventMessage
from dbo.AuditingEvents Ev
inner join dbo.AuditingActionTypes typ
on ev.ActionTypeID = typ.ActionTypeID

NPM 12.3 has shipped and we're hard at work building the next release.  Here's what we're working on, in no particularly order.

• Cisco ACI Monitoring
• Remote Collector - New, agent based collector for distributed environments and hybrid deployments
• Next Generation Orion Mapping - First version delivered in NPM 12.3 via Orion Platform 2018.2.  Working on the next version.
• Centralized Upgrades
• Website & Database Performance Improvements
• Windows Device Guard Support
• SAML Authentication Support
• Replace syslog/trap with the functionality from our new Log Manager product

I'd like to use NetPath to monitor the same IP address and port from multiple APE's, but NPM doesn't appear to allow it.

I have two remote sites hosting APE's. 

Each site is connected to a home site via two geographically diverse paths.

The remote sites route MPLS to the home site using two BGP peers--a .1 and a .5.  These peer addresses are on two different routers at the home site.

The two addresses reflect diverse paths that have a path distance of 250 miles--significant for latency.

I'd like to use NetPath to monitior the paths and latency to these two BGP peers from different APE's located each of the two remote sites.

I find I cannot do this monitoring in one instance of Solarwinds because NetPath doesn't see a difference in monitoring by source APE when the destination address and port have already been used once elsewhere.  I realize I could set a different destination port, but that's not the preferred method.

How can I use NetPath to monitor the same IP address and port from multiple APE's?