Submit a ticketCall us

AnnouncementsFace your biggest database issues head-on

Our new eCourse helps you navigate SQL Server performance blocks by teaching you how to recognize and deal with the three DBA Disruptors: Performance Hog, Blame Shifter, and Query Blocker. Register today to learn how to defend your environment and fend off menacing disruptions.

Register for your free eCourse.

Home > Success Center > Network Performance Monitor (NPM) > NPM - Knowledgebase Articles > Technical troubleshooting for common ConnectNow issues - Part 4

Technical troubleshooting for common ConnectNow issues - Part 4

Technical Troubleshooting Steps - Part 4


The following procedure provides additional general guidance for addressing ConnectNow issues.

  1. Check for multiple IP addresses.
    1. Orion does not support multiple IP addresses for nodes, as in the case where a device is accessible from multiple subnets.
    2. If a node has multiple IP addresses, try either of the following:
      Note: If you see this, contact Will Rodenbusch for a buddy drop to help with this issue.
      1. Orion NPM should manage the one that shows up in the ARP table.
      2. Add a node for each IP address to see which one works for ConnectNow.
  2. Another option is to test with LANSurveyor. For more information about LANSurveyor, see
    1. If LANSurveyor does not draw a connection, neither will Network Atlas.
    2. If LANSurveyor draws a connection, confirm that it is a direct connection and not merely the case that both nodes are connected to the same subnet.
    3. If LANSurveyor draws a direct connection, contact Dev to investigate further.
  3. False Positives
    1. If you are seeing connections that do not exist, there is probably an ARP table somewhere on the network with many wrong IP addresses for a single MAC address.
      1. This could happen if a host does not properly clear its ARP table for a long period of time.
      2. Flush the ARP table to clear old entries.
    2. Look for the MAC address that is to blame in the ARP tables of the devices in the discovery.
  4. Submitting Cases to Development
    1. Before submitting a case to development, gather the following required information:
      • Identification of the nodes that known to be physically connected but not connected by ConnectNow. The more details of the expected connection, the better (IPs, subnet masks, MACs, port number, VLAN or not…)
      • SolarWinds Diagnostics
      • Any additional info on the switch: Brand/model name, VLANs enabled/disabled, stacked or not…
      • Switch Port Map (export as CSV) of the switches in question
      • The output from show cdp neigh and show cam dyn, show mac-addr, or similar from the Layer 2 device.
    2. The following information would also be helpful:
      • A LANSurveyor map, created with the same settings as the Discovery, and the LANsurveyor_Log.txt file, generated with all logging settings enabled.
      • A screenshot of Network Atlas after completing ConnectNow.
      • A wireshark capture of the Network Sonar Discovery session
      • A wireshark capture of the LANSurveyor session, if available
      • SNMP image of the switch in question
      • The output of a command line switch port map from the Engineer's Toolset with the /showraw switch. enabled.
        For example, SWSPMCMD <IP> <Community> /showrow > mapfile.txt
  5. Check the Database. As a last resort, confirm that the database contains discovery data, as follows:
    Note: This confirmation can help development in the debug process.
    1. Open SQL Server Management Studio or Solarwinds Database Manager.
    2. Confirm that the TopologyData table contains data.
      Note: Check specifically for one of the connections that you are not seeing via ConnectNow by comparing with Nodes table. If there is data, Network Sonar Discovery is executing.
    3. If there is no data in the TopologyData table, check the Discovery tables for data.
    4. Confirm that the DiscoveryNodes table contains data.
    5. If there is no data in the DiscoveryNodes table, either Network Discovery has failed or no nodes were imported. Confirm that discovery has completed
    6. Confirm that the DiscoveryEdges table contains data.
    7. If there are no edges, the discovery engine did not find any connections.
  6. Review Diagnostics
    1. The DB folder contains diagnostics for the database tables discussed previously.
    2. The LogFiles/DiscoveryEngine folder contains the logs created by Network Discovery:
      • DiscoveryJob.log may contain errors.
      • DiscoveryJob.log contains the raw xml results from the discovery
    3. There may also be errors in LogFiles/BusinessLayerHost.log relating to discovery.

This article applies to:
Orion Network Atlas version 1.2 and higher

Last modified