14 Replies Latest reply on Mar 7, 2018 1:58 PM by mesverrum

    viewing the topology?

    cameramonkey

      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?


        • Re: viewing the topology?
          mesverrum

          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?
            jamesatloop1

            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?
              jamesatloop1

              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

                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.

                1 of 1 people found this helpful
                  • Re: viewing the topology?
                    mesverrum

                    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

                        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

                            Unreachable nodes are not polled at all until their parent comes back up.

                              • Re: viewing the topology?
                                RichardLetts

                                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

                                    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

                                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.