Submit a ticketCall us

whitepaperYour VM Perplexities Called, and They Need You to Read This.

Virtualization can give you enormous flexibility with future workloads and can be a key enabler for other areas, like cloud computing and disaster recovery. So, how can you get a handle on the performance challenges in your virtual environment and manage deployments without erasing the potential upside? Learn the four key areas you need to be focusing on to help deliver a healthy and well-performing data center.

Get your free white paper.

Home > Success Center > Network Performance Monitor (NPM) > Knowledgebase Internal > 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



Internal Use Only