This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

viewing the topology?

I know there is a setting to "calculate dependencies automatically" but everyone I have ever talked to said to never ever use it.

Is there a way to preview it to see what it THINKS the network topology is?


  • No preview is available, if you enable it then it creates all the dependencies it can and they all have "auto" in the name.  If you do use it then you would need tor eview the links it thinks it found for errors.  A common mistake I've seen is when it shows POE wireless ap's as the parent of their switch.

  • If you enable the auto, are you able to disable the individual dependencies it creates, or is it an all or nothing?

  • Yes you can override it. I had no dependencies and turned it on to see what happen, it was fine. Nearly all network stuff, some right, some needed love. I thought it was a good start, better than starting from nothing.

  • Yes you can in network atlas, drop the nodes into network atlas and enable link utilization and labels. The grey links are the guess work, the blue links with labels are correct. I use auto dependencies all the time. The are correct as long as the correct interfaces are being monitored, they are only wrong when the interfaces are being monitored.

  • Is network atlas part or Orion or NPM? I can't seem to find it.

  • Its the map editor. Add a map to a view and one of the component options is to add a link to download the app to install.

  • Log onto your orion server and serch the start menu for 'atlas'. It should pop right up. Log in with your orion credentials.

  • Rather than avoiding the Auto-Dependencies, I suggest enabling them and then reviewing them to see what results are generated.  I use them across a hundred hospitals and clinics to great effect, and after reviewing them to verify they all make sense, I only found three that weren't perfectly rational.  In each case Solarwinds had placed a Parent device as dependent on a Child device.

    For example, remote access to a UPS is dependent on its site's router to be up, but the Auto-Dependency had incorrectly placed the Router as dependent on the UPS.  In a real-world power-oriented and ironic point of view, this is actually truth--the Router needs power from the UPS.  But it's not the way I need it working in Solarwinds, so I overrode it and put the Router as the Parent and the UPS as a the Child/Dependent.  It's easy to do.

    The automatically generated dependencies are a real time saver for me.  Maybe you'll find that to be the case for your organization, too.

  • As long as you review them all it can be helpful, but it doesn't have the intelligence to handle things like alternate failover paths or SDN/SDWAN etc and it can be a real pain to lose one of your paths and then realize that Solarwinds has stopped polling everything downstream without even realizing you can still reach the site via your second router.  It does no validation before it starts marking things unreachable and I have walked into a lot of client environments where Solarwinds understanding of their topology was much more inaccurate than just 3 relationships.  I find the error rates to be closer to 5-10% in the places I've worked.

  • does it actually stop polling, or does it simply mark the node as unreachable instead of down (if it would have marked it as down.)

    the former implies, as you suggest, that it needs a complete understanding of your topology and failover, which in my case requires it to understand VRRP and BGP (something NPM is really quite poor at)