-
Re: viewing the topology?
mesverrum
Sep 5, 2017 5:35 PM
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.
-
Re: viewing the topology?
If you enable the auto, are you able to disable the individual dependencies it creates, or is it an all or nothing?
-
Re: viewing the topology?
jm_sysadmin
Feb 1, 2018 9:31 AM
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.
-
-
-
Re: viewing the topology?
jamesatloop1
Feb 1, 2018 6:07 PM
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.
-
-
Re: viewing the topology?
jm_sysadmin
Feb 2, 2018 8:06 AM
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.
-
-
-
Re: viewing the topology?
jamesatloop1
Mar 6, 2018 10:01 AM
Log onto your orion server and serch the start menu for 'atlas'. It should pop right up. Log in with your orion credentials.
-
Re: viewing the topology?
rschroeder
Mar 6, 2018 10:14 AM
1 of 1 people found this helpfulRather 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.
-
Re: viewing the topology?
mesverrum
Mar 6, 2018 11:39 AM
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.
-
Re: viewing the topology?
RichardLetts
Mar 6, 2018 5:00 PM
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)
-
Re: viewing the topology?
mesverrum
Mar 6, 2018 5:10 PM
Unreachable nodes are not polled at all until their parent comes back up.
-
Re: viewing the topology?
RichardLetts
Mar 7, 2018 10:46 AM
I am not sure you are right. Have you tested this?
[this is a building under construction, and I changed the polling addressed of the nodes so they would appear down while testing this]
1. change the building aggregation switch to make the parent appear down
This is what I see for a node that still has connectivity, even if its parent is down:
2. Changed the polling address of the edge switch (the child)
It got flagged as unreachable:
3. Restored the polling address of the edge switch
Orion NPM [correctly] flagged it as up (which it would not do if it was not still polling the node)
This is with NPM 12.1 -- and this behavior looks correct, and what I would expect.
-
Re: viewing the topology?
mesverrum
Mar 7, 2018 1:58 PM
Interesting, I've definitely seen it misunderstand the relationships and make whole swaths of servers as down when they were still reachable due to other paths, and cases where the child parent relationships were backward and when the child went down the parent showed as unreachable, despite still being up. Maybe this was fixed in more current later release than when I was running into those issues. I generally stopped using the auto dependencies in the 11.x era, and moved to just running sql queries to build them out by hand so it's logic could have improved since then.
-
-
-
-
Re: viewing the topology?
rschroeder
Mar 7, 2018 11:10 AM
Yes, reviewing them IS required, although I think it shouldn't be.
They do a good job for hub & spoke environments with little WAN resilience. Maybe that additional feature of properly discovering resilient paths will be Gen 2 for NPM in the near future. One can hope.
-
-
